Metadata

Rangler does not currently expose a customer writable metadata parameter on public API resources.

This page explains how metadata will work when it is added to resources managed through the portal API.

Use metadata for customer controlled key value data that helps your own system connect Rangler resources to your internal records.

Metadata helps you match Rangler objects to records in your own system. It does not change Rangler behavior.

Supported Shape

Metadata is a flat object.

Keys and values should be strings. Keep values small and avoid nested payloads.

{
  "metadata": {
    "internal_company_id": "co_94218",
    "watchlist_id": "wl_primary_equities"
  }
}

Good Uses

• store your internal company identifier on a watchlist entry
• store your internal workflow identifier on a webhook subscription
• store a reference ID for jobs that read event feeds
• store a non-sensitive environment marker such as sandbox_eval

Bad Uses

• do not store secrets or credentials
• do not store personal financial data
• do not store data needed for access control
• do not store large JSON payloads
• do not rely on metadata to change webhook delivery or event visibility

Python

No public SDK method accepts metadata yet.

metadata = {
    "watchlist_id": "wl_primary_equities",
    "owner_team": "research",
}

Do not send arbitrary metadata to endpoints that do not document it. Unsupported fields can be rejected or ignored.

Limits

Use metadata sparingly.

• maximum 50 keys
• maximum key length of 40 characters
• maximum value length of 500 characters
• keys must not contain square brackets