From a few verbs
to your first call.

Your first bin

1. Create an account and verify your email. Follow the confirmation link before entering the editor. Check spam or use Resend verification email if needed.
2. Create a bin. Give it a name and choose a starter template, or paste your own JSON array. This small example speaks a greeting and hangs up.

[
  { "verb": "say", "text": "Hello from Jambins." },
  { "verb": "hangup" }
]

3. Save the bin. Both JSON syntax and the jambonz schema must pass. Saving generates your content and status URLs.
4. Connect jambonz. Paste Content webhook into your application's calling webhook and Status webhook into its call status webhook. Choose POST for both. Configure your phone number, speech vendors, and voice in jambonz, then make a test call.

One bin, a stable home

Each account has a private collection of bins. A bin has a name, an immutable UUID, saved application JSON, an enabled state, and two independent URL secrets.

Syntax and schema are separate checks

Validation runs while drafting and again before saving. A warning flags steps after a hangup; warnings do not block a save. Schema validity does not predict call behavior, vendor availability, or the success of external action hooks. Jambins stores the application; jambonz executes it.

Callbacks, counts, and unread events

Open Status events to inspect the received payload, call ID, status, method, and timestamp. History is newest first, with 50 events per page and a button to load older events.

• The selected saved bin's count refreshes every 10 seconds, including on the Application tab.
• A small red dot marks unread events. Only events displayed in a visible Status events panel are marked read.
• Read markers survive bin switches and reloads in the same browser and website. They do not sync across devices or site domains.
• History is kept for seven days and removed by scheduled cleanup. Clear history removes it sooner.

Callbacks can contain JSON, form fields, or query fields. Common credential fields are redacted, but this is not a complete personal-data filter. Choose what your applications send. Repeated callbacks are stored separately; there is no automatic deduplication.

Account and access

Verify before editing

Signup requires an email, a password of 12–256 characters, and acknowledgement of the privacy and service terms. New accounts can manage their account but cannot create or view bins until verified.

A full day signed in

Sessions last 24 hours from sign-in, with no shorter inactivity timer. Polling does not extend that lifetime. Temporary sign-in-check failures offer a retry and preserve the draft.

Change or recover a password

Account settings requires your current password to set a different new password. Forgot your password? emails a one-hour, single-use link. A successful reset revokes all sessions; sign in again with the new password.

Delete your account

Confirm with your current password and DELETE. Webhooks are disabled immediately, then all owned bins, callback history, and the account are removed. Cleanup waits about a minute for in-flight requests and can resume if you close the page.

Content, webhook secrets, and callback payloads are encrypted at rest. Keep a separate copy of important call flows. Jambins is offered free and as-is; see the imprint and privacy policy for service and data information.

Content & status webhooks

Copy these URLs from a saved bin. Replace the placeholders below with that bin's ID and the matching secret. The two secrets differ. No login cookie or management API headers are required.

Content

GET / POST /b/<BIN_ID>/content?k=<CONTENT_SECRET>

Returns HTTP 200 with Content-Type: application/json and the saved jambonz array. The request payload does not change the returned flow.

curl --request POST \
  'https://api.jambins.com/b/<BIN_ID>/content?k=<CONTENT_SECRET>' \
  --header 'Content-Type: application/json' \
  --data '{}'

The response is the application array itself, without an ok or bin wrapper.

Status

GET / POST /b/<BIN_ID>/status?k=<STATUS_SECRET>

A POST accepts a JSON object with application/json or fields with application/x-www-form-urlencoded. A GET records its query fields except k. Both call_sid/call_status and callSid/callStatus are recognized.

curl --request POST \
  'https://api.jambins.com/b/<BIN_ID>/status?k=<STATUS_SECRET>' \
  --header 'Content-Type: application/json' \
  --data '{"call_sid":"example-call","call_status":"completed"}'

{ "ok": true }

A 404 can mean the URL is incorrect, a secret was rotated, the bin is paused or deleted, or its owner is unavailable. The response deliberately does not reveal which condition applies. Unsupported methods return 405; a status POST with an unsupported content type returns 415. A storage failure returns 503 rather than acknowledging a lost callback.

Health

GET https://api.jambins.com/health returns {"ok":true} with HTTP 200 when backend initialization succeeds. It does not test a bin or place a call.

Management API

Base URL: https://api.jambins.com. All paths below are relative to it. Requests and responses use JSON, except successful HTTP 204 responses, which have no body. The legacy website uses its original function host for management requests.

const base = 'https://api.jambins.com';
const accountResponse = await fetch(base + '/api/me', {
  credentials: 'include'
});
if (!accountResponse.ok) throw new Error('Sign in first');
const { csrf } = await accountResponse.json();

const application = [
  { verb: 'say', text: 'Hello from the API.' },
  { verb: 'hangup' }
];
const response = await fetch(base + '/api/bins', {
  method: 'POST',
  credentials: 'include',
  headers: {
    'Content-Type': 'application/json',
    'x-bin-client': 'web',
    'x-bin-csrf': csrf
  },
  body: JSON.stringify({
    name: 'My greeting',
    content: JSON.stringify(application)
  })
});
if (!response.ok) throw new Error('Could not save the bin');
const { bin } = await response.json();
// bin.contentUrl and bin.statusUrl contain access secrets.
// Use them in jambonz; keep them out of logs.

{
  "syntaxValid": true,
  "schemaValid": true,
  "issues": [],
  "warnings": [],
  "schemaVersion": "0.4.23"
}

Errors and service limits

Error bodies have the shape {"error":"Readable message"}. API and webhook responses use Cache-Control: no-store. Keep retries bounded, especially for status callbacks: retrying may create another event.

Verification exchanges and recovery confirmations are limited to 10 per IP/10 minutes. Verification resend: 3 per account/hour. Recovery requests: 5 per IP/hour and 3 per email/hour. Password changes and deletion password checks: 5 per account/10 minutes each. Deletion continuation: 40 per account/minute.

The service is intended for prototyping and modest traffic. There is no call execution engine, webhook signature check, automatic deduplication, cross-device read sync, or availability commitment.