Authentication

Site integrations use the same API key as the rest of Web Access. Send it as a Bearer token in the Authorization header of every POST to an action:

Authorization: Bearer YOUR_API_KEY

The examples on the catalog pages read the key from an environment variable, $STRING_API_KEY. Set it once in your shell and paste the examples as they are:

export STRING_API_KEY="your key"

The GET routes that describe the integrations (the catalog and the schemas) are public and need no key. See Making a request.

Getting a key

1. Sign in to the String dashboard and open Settings.
2. Under Your API keys, select Generate key.
3. Copy the key from the dialog. It's shown once; after you close the dialog it can't be viewed again.

An organization can hold up to 100 active keys. Every key spends the same organization balance, so a separate key per application lets you revoke one without affecting the others.

How your key is used

The integrations service holds no key of its own. When you call an action, it forwards your key on every request the action makes to /v1/fetch. Web Access checks the key, your balance, your access rules and your rate limit on each of those requests, exactly as it would for a request you sent yourself.

That has two consequences:

• Anything your key can't do through /v1/fetch, it can't do through an integration either.
• Each request an action makes is billed to your organization, and counts towards your rate limit. One call can make several requests; the response lists them.

Errors

When Web Access refuses your key, the whole call stops and you get Web Access's own status and body, unchanged. There is no partial result, because the same refusal would apply to every remaining request.

{ "error": "Invalid API key" }

The full list of statuses an action can return is in Responses & errors.