Overview

An agent is looking at a ticket about a late delivery. The question is simple — where is this shipment? — and the answer isn't in Assistive. It's in your systems.

Today that means the agent leaves the helpdesk, digs through an internal tool, or pings an engineer on Slack. Context Sources close that gap. You register a read endpoint on your own server, and agents can pull the answer into the ticket without leaving it.

This is the inverse of our other integrations

Worth getting straight before you read further, because it changes who calls whom:

With the Public API you write a client. Here you write a server. We are the caller, your endpoint is the callee, and the security problem runs the other way: instead of proving who you are to us, you need to satisfy yourself that an inbound request really came from us. That's what the signature is for.

How it works

Three steps, and only the first two involve writing code.

1. Build a read endpoint on your server — say GET /shipments/{id} — that returns JSON.
2. Verify our signature on every inbound request, so you know the call is genuinely from Assistive and not from someone who found your URL.
3. Register it in the dashboard, declaring which parameters it takes and which fields of the response agents should see.

Then an agent on a ticket picks your source, types a shipment ID, and the mapped fields appear on the ticket.

When to use this

Use a Context Source when the answer changes and lives in your system. Shipment status, subscription tier, account balance, last invoice, feature flags for that user — anything an agent would otherwise have to go and look up somewhere else, every time.

Don't reach for it when a human could just paste the value in. If the data is stable and rarely needed, the setup cost isn't worth it. Context Sources earn their keep on the lookups your team does dozens of times a day.

What it is not

Be clear on the boundaries before you design around them:

• Read-only. A lookup fetches data. There is no write path, no way for an agent to change something in your system through a source.
• Agent-triggered, not automatic. Nothing fires on its own. An agent chooses a source on a ticket and runs it. There are no webhooks, no push, and no background sync.
• Parameters are typed by the agent. In this version, the agent enters the values. A source does not automatically receive the ticket's customer, the ticket ID, or anything else about the context it was run from.
• No retries. A lookup is one request to your endpoint. If it fails, the agent sees why and can run it again.

What agents can and can't see

This is a real security property, and it's worth knowing when you decide what to point a source at.

An agent running a lookup sees only the source's name, description, and parameters. They never see:

• the URL template — so they can't learn what internal host it points at;
• the custom headers — so a static credential you put there stays secret;
• the signing secret.

An agent can therefore use an integration without being able to extract the credentials behind it, or discover the shape of your internal infrastructure. The person who configures a source and the people who use it are deliberately different trust levels.

Next