Skip to main content
Workspace admin

IntELIEKonnect API

The IntELIEKonnect partner API covers bindings only: the routing rules that say where a connector's data goes. "Documents this mailbox pulls land in that orchestrator" is a binding.

Everything here needs an API key and the 15-minute pass it exchanges for: how to get both. Paths below are relative to /external/v1/konnect.

Every endpoint​

MethodPathScopeWhat it does
GET/connectors/{connectorId}/bindingskonnect:bindings:readThe bindings on one connector. Filter with product and status (enabled or disabled).
GET/bindings?product=&target_ref=konnect:bindings:readWhat feeds one target, across all connectors. Both parameters are required.
POST/connectors/{connectorId}/bindingskonnect:bindings:writeBind a connector to a target.
PATCH/connectors/{connectorId}/bindings/{bindingId}konnect:bindings:writeTurn a binding on or off.
DELETE/connectors/{connectorId}/bindings/{bindingId}konnect:bindings:writeRemove the binding. 204, no body.
Give an IntELIEKonnect key the whole account

When a key's Reach is set to Only these resources, it can reach no connector at all, because the workspace offers no way to pick connectors there. Every call on a connector then answers 404, and GET /bindings comes back empty. Give a key you use here Everything in this account.

Creating a binding​

curl -X POST "$BASE/external/v1/konnect/connectors/$CONN/bindings" \
  -H "Authorization: Bearer $PASS" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{"product":"inteliedoc","target_ref":"wq_01H8XK3M9P"}'

product is inteliedoc, kb or voice. target_ref is the workqueue, knowledge base or voice app id: the same id that product's own list returns. An optional required (true or false, default false) is stored with the binding. A new binding answers 201.

The older targetRef spelling is still accepted in the request body, and as a query parameter on GET /bindings, so an existing integration keeps working. Write new code against target_ref: it is the spelling every response uses, so mixing the two leaves you sending one name and reading back another.

Both sides must already exist. A binding joins two things a person set up in the workspace; it creates neither.

  • The connector must be Initialised or Active, and Connected unless its type needs no credentials. Anything else answers 422 schema_invalid.
  • The target must be one your key can see. If Elie cannot check the target at that moment, the call answers 503; try again later.
A target you cannot see and a target that does not exist both answer 404

That is deliberate, and it is the same rule the rest of the API follows: if the two were different, an id could be probed to discover what an account holds. If you are sure the target exists, check the key's Reach in the workspace; usually the key is restricted.

Binding the same connector to the same target twice is not an error. The existing binding comes back unchanged with a 200, so a retry after a timeout is safe. The one exception: if the connector has stopped being bindable since, the retry gets the 422 instead.

Turning a binding off​

curl -X PATCH "$BASE/external/v1/konnect/connectors/$CONN/bindings/$BINDING" \
  -H "Authorization: Bearer $PASS" \
  -H "Content-Type: application/json" \
  -d '{"enabled": false}'

enabled is the only thing you can change, and it is required. Sending priority, format_spec or delivery_semantics_hint answers 400, because those are delivery settings that stay in the workspace. Any other field you send is ignored, so check the response rather than assuming a change took effect.

Turning a binding off is how you pause routing. Deleting it ends routing. Data already delivered is unaffected either way, and deleting a binding leaves both the connector and the target untouched.

What is not here, and will not be​

No endpoint creates a connector, authorises one, sets its type, tests its credentials, triggers a fetch, runs a sign-in with a provider, resets where it reads from, or manages credentials. No scope unlocks any of it.

That boundary is what makes routing safe to expose at all: a partner can only wire together two things a person already set up, and a connector has to be ready to run before it can be bound to anything.

Full schemas​

Field-level request and response shapes are in the workspace: open Developers, then API explorer. The API reference there is generated from the running service, so it cannot drift. This page is the capability reference.

Last updated on Something wrong with this page?