Providers

A provider identifies an external system and owns its provider settings and custom-field namespace. It is not an OAuth client and it is not a tenant setting group.

Provider workflow

  1. Create the provider metadata and choose a stable group.
  2. Define provider-owned configuration through Provider Settings.
  3. Import the provider's fields and map them through Custom Fields & Mappings.
  4. Exchange resource records using their identifier values.

The provider group associates schemas, settings, and mapped fields. Record identifiers are opaque external strings assigned by the source system.

A provider resource contains id, name, description, group, legal_name, privacy_policy_url, support_url, created_at, and updated_at. settings is included only when that relation is explicitly loaded.

GET/api/v1/providers

List providers

Returns provider resources. Required scope: providers:read. Standard collection parameters such as limit, perPage, and with=settings are supported by the shared API query layer.

POST/api/v1/providers

Create a provider

Required scope: providers:write. name (2–64 characters) and group are required. Optional fields are description (5–2056 characters or null), legal_name, privacy_policy_url, and support_url.

{
  "name": "Example ERP",
  "group": "ExampleErp",
  "description": "Synchronizes customer and ticket records.",
  "support_url": "https://example.com/support"
}
GET/api/v1/providers/{provider}

Get a provider

Required scope: providers:read. {provider} accepts the provider group or record ID. Use the group in integrations because it is the stable namespace.

PATCH/api/v1/providers/{provider}

Update a provider

Required scope: providers:write. PUT is also registered. The request uses the same fields and validation rules as creation; currently name and group remain required.

DELETE/api/v1/providers/{provider}

Delete a provider

Required scope: providers:write. Returns 204 No Content.

Was this page helpful?