Appearance
Developer settings
Settings → Developer is where Blok connects to everything else: Make scenarios, QuickBooks, n8n, or anything else that needs to read your data or react when something happens.
There are two halves, and they do opposite things:
| Direction | Use it when | |
|---|---|---|
| API keys | Something calls into Blok | A scenario needs to read or change your data |
| Webhooks | Blok calls out | Something needs to know the moment an event happens |
Most integrations use both: a webhook tells the scenario when to act, and the API key lets it fetch details and write results back.
API keys
A key is a password for a machine. It always belongs to your organization and can only do what its scopes allow.
To create one: Settings → Developer → API keys → Create a key. Give it a name describing what will use it ("Make: QuickBooks scenarios"), tick the scopes it needs, then copy the key immediately. It's shown once and never again. Only a scrambled hash is stored, so nobody, including us, can recover it. Lose it and you revoke and create a new one.
Choosing scopes
Grant the least a job needs. Ticking Write automatically includes Read, because writing without reading is almost never useful.
A QuickBooks invoicing scenario needs only Invoices: Read + Write. It does not need access to employees, timesheets, or customers.
Revoking
Revoke stops the key working immediately and permanently. Anything using it breaks at once. Revoked keys stay listed so there's a record of what existed. Revoke when a scenario is retired, when someone with access leaves, or any time a key might have been exposed.
Webhooks
A webhook makes Blok POST a small message to a URL whenever something happens, so an integration reacts in seconds instead of polling.
To add one: Settings → Developer → App webhooks → Add a webhook. Paste the endpoint URL (https only, usually copied from a Make scenario's webhook module), pick which events should trigger it, and save. As with keys, the signing secret is shown once, so copy it then.
Picking events
Events are grouped by area, with a plain-English name and the technical name beside it. Selecting nothing means every event, which is convenient for testing and noisy in production. Narrow it once you know what you need.
Example: the QuickBooks scenario listens only for Invoices → Ready to send (
invoice.ready), which fires the moment someone marks an invoice ready.
If an event isn't listed yet, Add an event not listed accepts the exact name.
The signing secret
Every delivery carries a signature computed from the secret, letting your endpoint prove the message genuinely came from Blok and wasn't tampered with. Treat it like a password. If you lose it, delete the webhook and add it again.
Pause vs delete
Pause stops deliveries but keeps the configuration, which is right for temporarily quieting an integration. Delete removes it entirely.
If deliveries fail
Blok retries with increasing gaps before giving up. A webhook that never seems to arrive is usually an endpoint that isn't publicly reachable, isn't https, or is rejecting the signature.
Who can change these
Both sections are admin-only. Other members can see what exists but not create, change, or revoke. The badge on each section header shows how many are currently active.
Related
- Per-form webhooks are different and narrower: configured inside the form builder, they fire for one specific form. Use those to route a single form's submissions; use app webhooks for org-wide events.