Build Blip into your app.

Is this key set up right, and what's left to do? The workspace, the key's scopes, its app and webhook address, your support buttons with the code to paste for each, the plugin's latest version, and next_steps: plain sentences for whatever is still missing. It answers even when your plan doesn't include the API, with api.ok false and why.

{
  "workspace": { "id": "...", "name": "Acme", "windows": false },
  "key": { "name": "Help desk", "prefix": "blip_sk_4f1c", "scopes": ["videos:read", "videos:write"] },
  "app": { "slug": "help-desk", "name": "Help desk", "active": true,
    "webhook_url": "https://acme.com/api/blip/webhook", "events": ["video.ready", "ticket.created"],
    "sites": ["app.acme.com", "localhost"] },
  "api": { "ok": true },
  "support_buttons": [{ "name": "Acme app", "active": true, "files_with_this_app": true,
    "sites": ["app.acme.com"], "snippet": "<script src="https://sendablip.com/plugin/v1/support.js" ...></script>" }],
  "plugin": { "version": "2.27.0", "files": { "server": "https://sendablip.com/plugin/v1/blip.ts", ... } },
  "next_steps": []
}

A link to Blip's recorder for your own team. Whoever opens it signs in to Blip and must be in your workspace. For your app's users, who have no Blip account, make a request instead. Either way, recorder.js opens it from your button:

<script src="https://sendablip.com/plugin/v1/recorder.js" async></script>
<!-- Your route POSTed, answering {url} from /recorder-links or /requests -->
<button data-blip-record="/api/blip/record" data-blip-ref="yourapp:project:42">Record a Blip</button>

{ "url": "https://sendablip.com/record?t=...", "expires_at": "2026-11-09T18:00:00.000Z" }

The recorder inside your own page, with no new window and no second sign-in. Your server asks for a session for one person on your site; the browser opens it with the hosted script. A session works only on origin and runs out after six hours. During early access this is switched on for each app with us.

<script src="https://sendablip.com/plugin/v1/recorder.js"></script>
<script>
  // url comes from your server's call to /recorder-sessions
  BlipRecorder.open(url, { anchor: recordButton });
</script>

Who can see what, by your own rules. Run your own query as this person, so your own permissions decide, and send every ref they can see. It replaces their list for your app; an empty list removes everything. Send it for every person, not only the ones who open Blip, and again whenever their access changes. Add /manage to a ref (acme:project:42/manage) when they can change other people's videos there too.

{ "synced": 12 }

Your places and their names: acme:project:42 is “Acme website”. Blip shows the names, and offers the places a person can see (PUT /access) when they file a Blip. It replaces your last list. An archived place keeps its name but isn't offered. A place named <your-app>:project:<uuid> becomes one of the workspace's projects in Blip, beside the ones it makes itself; one you stop sending is archived, never deleted.

{ "listed": 22 }

Everyone your app lets into Blip in your workspace, by your own rules. It replaces your last list: people on it become members, now or when they first sign in to Blip, and members your list made who aren't on it any more stop being members. People your workspace's owners add in Blip aren't touched. Send it on a schedule and when someone joins or leaves.

{ "listed": 24 }

Your workspace's Blips, newest first. GET /videos/:id returns one.

{
  "videos": [{
    "id": "4f1c...", "title": "Q3 plan walkthrough", "status": "ready",
    "duration_seconds": 214, "external_ref": "yourapp:project:142",
    "created_at": "2026-11-09T15:02:11Z", "owner": { "name": "Mei Chen" },
    "guest_name": null, "source": "web", "views": 7, "request_id": null, "purpose": "blip",
    "share": { "code": "9cc6cf7bb13c36b3ae83eb03", "enabled": true,
      "url": "https://sendablip.com/9cc6...", "embed_url": "https://sendablip.com/embed/9cc6...",
      "thumbnail_url": "https://sendablip.com/api/video/thumb/9cc6....jpg" }
  }],
  "next_before": null
}

Status is uploading, processing, ready or failed.

embed_url takes ?t=30 to start 30 seconds in and ?title=0 to hide the title bar. An embed shows the video's picture and a play button, and loads the player when someone presses it, so nothing reaches the video host until then. It can't start by itself: ?autoplay=1 is still accepted, but it waits for that press too.

purpose says what each one is, set where it was made and never changed: blip (recorded or uploaded to share),support (a report through a support button or a team member's bug report) or reply (an answer to a Blip Reply, or a clip of answers). Blip's own library shows Blips only.

Rename a Blip, set or clear its ref, or turn its share link on or off. Send any of the three. DELETE /videos/:id deletes it: the link stops and its files go.

{ "video": { "id": "4f1c...", "title": "Q3 plan, final", ... } }

Every Blip gets a transcript, a summary, chapters and action items, made on Blip's side a minute or so after it's ready.

{ "transcript": {
  "state": "done", "language": "en",
  "text": "Hey everyone. Today I'm showing you...",
  "segments": [{ "start": 0.4, "end": 3.1, "text": "Hey everyone." }],
  "summary": "Three changes that cut onboarding time in half.",
  "chapters": [{ "start": 0, "title": "Why calls were slow" }],
  "action_items": [{ "title": "Record the setup walkthrough", "description": "...", "quote": "..." }]
} }

state is queued or running while it's being made, done with words, and no_speech, failed or none when there won't be any.

A Blip's comments, oldest first, each at its second in the video when it has one. A visitor's name is what they typed, marked guest.

{ "comments": [{ "id": "...", "body": "Can we keep the old button?", "at_seconds": 42,
  "created_at": "2026-11-09T16:20:00Z", "author": { "name": "Ruth Ellis", "guest": false },
  "task": { "label": "LP-150", "url": "https://..." } }] }

How a Blip is doing. The owner watching their own doesn't count.

{ "stats": { "views": 31, "viewers": 18, "minutes_watched": 64.5,
  "completed": 12, "button_clicks": 4, "reactions": { "🔥": 3, "👏": 5 } } }

A personal link to one Blip for one person, so you know when they watched.

{ "id": "b2e0...", "url": "https://sendablip.com/0123...cdef" }

A link anyone can record on, with no account: ask a customer to show you a problem, or a teammate for an update. The url comes back this once.GET /requests?ref= lists them; POST /requests/:id/new-link replaces the link (the old one stops) andPOST /requests/:id/revoke ends it.

{ "id": "...", "url": "https://sendablip.com/r/...?open=page", "open": "page" }

Made with an app key, open is page: recorder.js opens it inside your page, on the sites listed on the app. It's window only when your workspace allows pop-up windows and the app lists no sites. Emailed or pasted, the link is a page of its own either way.

A request's state is open, received, expired or revoked, with received_count and latest_video_id.

What one person was asked to watch and hasn't finished, with how far they got. ?user= is the person; &done=1 includes finished ones.

{ "assignments": [{ "video_id": "4f1c...", "title": "Onboarding", "external_ref": null,
  "due_at": null, "best_percent": 64, "completed_at": null, "assigned_at": "2026-11-08T10:00:00Z" }] }

Threads is a DM between a student and your team, inside your own app: video, voice or text both ways, with a coach, an assistant or your AI answering. It needs an app key and Threads switched on for the app. Your people are known by your own ids; they need no Blip account. Add them here, up to 500 at a time. active: false switches a person off, so who may use Threads (every member, or only people who paid) is yours to decide.GET /threads/people?role= lists them.

{ "saved": 3 }

POST /threads gives a student's DM, making it the first time (201) and returning the same one after (200): one DM per student and ref.GET /threads lists them. Pass ?for= a person's id for anything a person sees (a student gets only their own, and the groups they're in), and each thread then has unread: how many messages from others that person hasn't read.?state=waiting is the coach's inbox, the longest-waiting first. Also ?assigned= (an id, or none), ?student=,?kind=dm|topic|group, ?parent=, ?ref=, ?archived=true, ?limit= and ?before=.

GET /threads/:id reads one. PATCH /threads/:id with {by, assigned_to?, answered?, title?} lets a coach or assistant (by) give it to someone (null: nobody), mark it answered without a reply, or name it. POST /threads/:id/split with {by, message_id, title?} moves a question out of a DM into a topic of its own (or out of a group: see groups).

{ "thread": { "id": "7d1e...", "kind": "dm", "student": { "id": "u_42", "name": "Nathan", "role": "student" },
  "ref": "course:ai", "assigned_to": null, "waiting_since": "2026-11-13T15:02:11Z", "answered_at": null,
  "messages": 1, "last_message_at": "2026-11-13T15:02:11Z", "last_preview": "How do I price this?" } }

Post a message from one of your people (from, your id for them), or from your own AI with {"as": "ai", "text": "..."}. A student posts only in their own threads; a coach or assistant in any. A student's message starts the wait. A coach's or assistant's ends it and takes the thread if nobody has it; the AI's does neither.GET /threads/:id/messages lists them, newest first.

{ "message": { "id": "a41b...", "from": { "id": "c_7", "name": "Coach Bob", "role": "coach" }, "role": "coach",
  "kind": "text", "text": "Charge more.", "video_id": null, "voice": null, "reply_to": null, "created_at": "2026-11-13T15:20:00Z" },
  "thread": { "id": "7d1e...", "waiting_since": null, "answered_at": "2026-11-13T15:20:00Z" } }

A voice note is sound only. Your people can record one straight into the Threads screens. To send one yourself, post the sound file as the body of the same address instead of JSON, with its Content-Type and who it's from in the address (the plugin's postThreadVoice does this):POST /threads/:id/messages?from=u_42&seconds=42. Blip keeps the file as it is, so it costs far less than a video and doesn't use your video minutes. Its words are written out a few seconds later: voice.transcript_state goes from pending to done(none if nobody spoke), so read the message again for voice.transcript. Play it from voice.audio_url, which works for three hours.

{ "message": { "id": "c93d...", "from": { "id": "u_42", "name": "Nathan", "role": "student" }, "role": "student", "kind": "voice", "text": null,
  "voice": { "seconds": 42, "transcript": null, "transcript_state": "pending", "audio_url": "https://sendablip.com/api/threads/audio/c93d...?k=..." },
  "created_at": "2026-11-13T15:25:00Z" },
  "thread": { "id": "7d1e...", "waiting_since": "2026-11-13T15:25:00Z", "last_preview": "Voice note" } }

A group is one place where several students and your team talk together, like a cohort. POST /threads/groups with {name, ref?, members?, by?} makes one (201). With a ref (your name for the cohort or course), the same call again gives the group there is (200), so you can call it every time you sync. A group is a thread of kind group: list it with GET /threads?kind=group (add ?for= for one person's groups), and read and post with /threads/:id/messages, in text, video or voice.

Who's in it. Members are students, by your ids. Every coach and assistant of your app is in every group already. GET /threads/groups/:id/members lists them, PUT /threads/groups/:id/members with {members} makes the list exactly that, and POST /threads/groups/:id/members with {add?, remove?} changes it. A group holds 500 students at most. A student reads and posts in a group only while they're a member: take them out and it stops at once, and what they wrote stays. A student can't join or leave by themselves; your app decides. In the inbox screen a coach can start a group and add or take out students too.

Nobody waits in a group. It isn't a queue: it has no waiting_since, it isn't given to anyone, and PATCH /threads/:id refuses it. To follow a question, move it out: POST /threads/:id/split on a student's message (by a coach, an assistant or the student who wrote it) makes a private topic between that student and your team, which waits like any topic. The AI never answers in a group. A student's monthly video and voice minutes cover what they record in a group too.

Changing it. PATCH /threads/groups/:id with {name?, ref?, archived?}. Archived, a group is still read by its members, nothing new is said in it (a post answers 409), and it leaves the lists unless you ask with ?archived=true.

Telling people. A group's thread.message webhook carries members: the ids of the students who can read it, so you can notify them (all but the sender) and your team. The list stops at 200 ids; when complete is false, ask for the members. Blip doesn't notify anyone itself, and there are no @mentions yet.

{ "thread": { "id": "5b0c...", "kind": "group", "title": "Spring cohort", "ref": "cohort:spring", "student": null,
  "member_count": 24, "archived_at": null, "waiting_since": null, "assigned_to": null,
  "messages": 0, "last_message_at": null, "last_preview": null } }

// thread.message, in a group
{ "type": "thread.message", "thread": { "id": "5b0c...", "kind": "group", "title": "Spring cohort", "member_count": 24 },
  "message": { "id": "c93d...", "from": { "id": "u_42", "name": "Nathan", "role": "student" }, "kind": "text", "text": "Is the call recorded?" },
  "members": { "count": 24, "ids": ["u_42", "u_43", "u_51"], "complete": true } }

The drop-in screens: a student's conversation and your team's inbox, inside your own app, in your colour. Your server says who is signed in and gets a session for that one person, good for two hours on one of your sites. Put thread_url (a student) or inbox_url (a coach or an assistant) in the plugin's BlipThread or BlipThreadInbox, or in threads.js on any page. The person is added or brought up to date, so there's nothing to sync first; someone you switched off gets no session.

In the screen, people write, or record a Blip with their camera, their screen or both; they need no Blip account. A video shows as getting ready, then plays in the conversation. The inbox lists who's waiting, the longest first, and a coach or assistant can answer, give a conversation to someone, mark it answered or move a question to a conversation of its own. origin must be one of your app's sites (Blip, Settings, Developers): only that site can hold the screen. Make the session on your server, never in the browser. To tell people about a new message when they're somewhere else, use the thread.message webhook.

{ "token": "blip_th_...", "thread_url": "https://sendablip.com/threads/embed?view=thread&s=blip_th_...",
  "inbox_url": null, "expires_at": "2026-11-13T17:00:00Z",
  "user": { "id": "u_42", "name": "Nathan", "email": null, "role": "student" } }

// React: the url comes from your server (createThreadSession).
import { BlipThread, BlipThreadInbox } from "@bigsteele/blip/react";

<BlipThread url={session.thread_url} accent="#0F766E" about="course:ai" onUnread={(n) => setBadge(n)} />
<BlipThreadInbox url={session.inbox_url} accent="#0F766E" height="100%" onWaiting={(n) => setWaiting(n)} />

<!-- Any page: -->
<div id="coach"></div>
<script src="https://sendablip.com/plugin/v1/threads.js"></script>
<script>BlipThreads.mount("#coach", { url: THREAD_URL, accent: "#0F766E", onExpired: getANewSession });</script>

Options on both: accent (a hex), theme (light or dark; the person's device decides otherwise), height,about (your name for what a student's conversation is about: one conversation each) and onUnread, onWaiting, onMessage,onExpired. When a session runs out, make a new one and pass its address.

To open one conversation first (from a notification or a link), add &thread= and the thread's id to the address. It opens only if that person may read it.

In your own phone app. Inside a phone app's shell your pages aren't on a site, so origin is the shell's own address:capacitor://localhost on an iPhone, https://localhost on Android. List it on your app under Phone app addresses (Blip, Settings, Developers); it is matched exactly, never by wildcard, and opens Threads only. Every app built on the same shell has that address, so there Blip keeps websites out but can't tell one phone app from another: keep the session's address on your server and out of links and notifications. Notifications are yours to send, from the thread.message webhook. The recipe, with code, and what hasn't been tested on a real phone: THREADS-PHONE.md.

student_minutes is how many minutes of video one student may record into Threads in a calendar month: 60 unless you set it. Their recordings count against your workspace's minutes like any other recording, so this keeps one student from using everyone's. At the limit they can still write.0 means students write and send no video. Your coaches and assistants have no limit of their own. GET /threads/settings reads it.

student_voice_minutes is how many minutes of voice notes one student may send in a calendar month: 120 unless you set it. Voice is sound only, so it doesn't use your workspace's video minutes. 0 means no voice notes from students. Send either setting or both.

ai_mode and ai_monthly_answers are the AI's: see Threads: the AI.

{ "student_minutes": 60, "student_voice_minutes": 120,
  "ai_mode": "off", "ai_monthly_answers": 500, "ai_monthly_answers_max": 500, "ai_answers_used": 0 }

Blip's AI can give a student a first answer, only from material you give it. Your coach chooses what it does (ai_mode in PUT /threads/settings, or the AI switch in the inbox screen): off, which is how it starts; draft, where it writes an answer and your team sends, changes or throws it away; or answer, where it answers on its own. Its messages have role: "ai" and are labelled as AI in the screens. It never ends a student's wait or takes the thread: only a person does that.

The material. PUT /threads/knowledge adds a document: pasted text with a title, or one of your workspace's Blips for its transcript. Send the same ref again and the document is replaced. GET /threads/knowledge lists them, GET /threads/knowledge/:id gives one with its text, DELETE /threads/knowledge/:id removes it. A coach can paste text in the inbox screen too. Blip cuts each document into pieces and, for each question, finds the pieces about it by their words; the AI may answer only from those.

{ "document": { "id": "5b0c...", "kind": "text", "ref": "module-3", "title": "Module 3: Pricing your first offer",
  "video_id": null, "state": "ready", "characters": 4210, "created_at": "2026-11-13T15:00:00Z", "updated_at": "2026-11-13T15:00:00Z" } }

An answer. A few seconds after a student's message (a voice note or a video once its words are written out), the AI's answer arrives as a message of its own, and thread.message is sent. ai.sources are the documents it rests on. When your material doesn't cover the question it says so once, in a short note (ai.unknown), and leaves the question to your team. It gives no medical, legal or financial advice beyond what your material says, and treats what a student writes as a question, never as instructions.

{ "id": "e41a...", "from": null, "role": "ai", "kind": "text", "reply_to": "c93d...",
  "text": "Your coach's material says not to discount to close a sale. Offer a payment plan of three monthly payments instead.",
  "ai": { "sources": [{ "id": "5b0c...", "title": "Module 3: Pricing your first offer", "kind": "text", "video_id": null }],
          "unknown": false, "needs_person": false, "from_draft": false } }

Ask a person. Under every AI answer the student's screen has an Ask a person button. POST /threads/:id/person with {by} (the thread's own student) does the same from screens of your own: the thread is flagged (thread.person_asked_at), it is waiting, thread.person_asked is sent, and the AI stays out of that thread until someone on your team has written.

A draft. In draft mode nothing reaches the student until a person sends it. GET /threads/:id/draft reads the draft, POST /threads/:id/draft with {by, text?} sends it as that coach's or assistant's own message (with their changes, if text; message.ai.from_draft is true), and DELETE /threads/:id/draft?by= throws it away. The inbox screen shows it with Send, Edit and Discard. thread.ai.state says where the AI stands on the latest question: answered, unknown, draft, nothing (your material had nothing, so no draft), no_material, allowance or failed.

How many. Your app has ai_monthly_answers AI answers and drafts a calendar month (500 unless Blip changed it; you can set it lower). When they're used up the AI stays quiet until next month, the inbox says why, and every question still reaches your team as it always did.

What the support recorder sends: a ticket written, with screenshots, or with its recording. It's called from the recorder's own page, which holds your button's pass (ticket); people signed in to Blip use it for Blip's own Report a problem without one.

{ "ok": true, "ticket": { "number": 12, "ref": "SUP-214",
  "status_url": "https://sendablip.com/ticket/3f9a1c07b2d84e6a9c51f0e27b3d6a84" } }

ref is what to show them: your app's ticket number if it answered with one, otherwise Blip's, like #12. status_url is their status page for it.

One screenshot, sent as a form with file and ticket: PNG, JPEG or WebP, 8 MB at most. Blip checks what it is from the file itself. Name its id in the ticket's file_ids within a day, or it's cleared out. Screenshots are kept private; your app gets links on https://sendablip.com/api/files/... that work for 7 days, and stop when the ticket is deleted. A link answers ranges (Range: bytes=0-) and never sends you on to another address.

{ "id": "5b0e...", "content_type": "image/png", "width": 1440, "height": 900, "bytes": 412337 }

Your workspace's tickets, newest first. A filter that isn't right is refused with a 400, never ignored.

{ "tickets": [{
    "id": "7d1f...", "number": 12, "ref": "#12", "title": "I pressed Pay and nothing happened", "body": "...",
    "kind": "text", "severity": "minor", "status": "open", "status_words": "We've got it",
    "solved_by": null, "reopened_count": 0, "awaiting_team": false,
    "origin": "support_button", "page": "https://acme.com/checkout", "site": "acme.com",
    "visitor": { "name": "Dana Okafor", "first_name": "Dana", "email": "dana@example.com", "verified": false, "external_id": null },
    "assignee": { "id": "5b0c...", "name": "Ben", "email": "ben@acme.com" }, "tags": ["billing"],
    "button": { "id": "c2a9...", "name": "Website", "ref": null }, "app_ref": null, "app_url": null,
    "status_url": "https://sendablip.com/ticket/9f3a...",
    "created_at": "2026-11-12T15:04:05Z", "updated_at": "2026-11-12T15:04:05Z",
    "first_answer_at": null, "last_team_at": null, "last_visitor_at": null, "solved_at": null }],
  "next_before": null }

visitor is the same here as in every ticket event: verified is true when your server signed them (Verified visitors) or they were signed in to Blip, and external_id is the id you signed, or null.

GET /tickets/:number is one ticket, whole: everything the list gives, and browser, viewport, errors (the page's last errors), files (the screenshots; each link is on sendablip.com/api/files/ and works for 7 days), video (the visitor's recording: player_url, and transcript with its state, summary, chapters, action_items and text), messages (the thread, oldest first) and email (how your visitors get emailed).

A message's kind is answer (your team's), visitor (theirs), note (your team's own) or event (something that happened). visible_to_visitor says whether it's on their ticket page; it is never true for a note. Never show a note to a visitor. ?view=visitor gives the thread as its visitor sees it: no notes, none of your team's own events, no team member's id. Use it for anything you build for the visitor.

{ "id": "a41c...", "kind": "answer", "from": "team", "via": "api", "event": null, "visible_to_visitor": true,
  "author": { "id": null, "name": "Ben" }, "key": { "id": "e19b...", "name": "Triage bot" },
  "body": "Thanks for telling us. We fixed it, so try again.", "created_at": "2026-11-12T15:20:00Z",
  "video": null, "notice": { "state": "sent", "attempts": 1, "last_error": null }, "held": false }

PATCH /tickets/:number changes any of status, assignee and tags, and answers {ticket, changed}. Sending what's already so changes nothing (changed: []), so a PATCH is safe to send again.

{as: "team", body} answers the visitor. It goes on their ticket page, and ticket.replied goes to your email webhook and connected apps, so your own tool emails it from your domain. Blip sends the visitor no email. {as: "note", body} adds a note for your team: the visitor never sees it and no email tool is told. {as: "visitor", body} brings in the visitor's own reply that reached you by email (Replies by email): body is the email's plain text as it came, with message_id and attachments if you have them. It needs tickets:write only. It's kept as via: "email" and marked on the thread as by email, never as verified.

Send an Idempotency-Key header (anything, 200 characters at most) and the same key again on the same ticket adds nothing: it answers 200 with the first message and replayed: true. A first send answers 201.

{ "message": { "id": "a41c...", "kind": "answer", ... }, "ticket": { "number": 12, "status": "waiting", ... },
  "notice": { "state": "sent", "error": null }, "apps": 1, "replayed": false }

notice is how telling your email webhook went, or null when your workspace has none.

Who a ticket can be assigned to (your owner, admins and staff) and the tags a ticket can carry. Each person's role is owner, admin or staff.

{ "people": [{ "id": "5b0c...", "name": "Ben", "email": "ben@acme.com", "role": "admin" }], "tags": ["billing", "bug"] }

Tell Blip something happened, like a purchase. The Reply automations you set up decide whether to make invites, and when.

{ "duplicate": false, "invites": [{ "reply_id": "...", "invite_id": "...", "send_at": "2026-11-12T15:00:00Z" }] }

Make one invite yourself. GET /blip/invites?external_id=&email=&limit= lists them (50 by default, 200 at most).

{ "invite_id": "...", "url": null, "duplicate": false }

Cancel by {external_id} or {invite_id}, for a refund say. Anything of theirs that was published comes down. POST /blip/erase with {email} removes a person's answers and clips everywhere.

{ "cancelled": 1, "taken_down": 0 }

The webhooks Blip sent your app, or is still trying to send: newest first, 50 by default and 200 at most. Filter with ?state=(queued, sent or failed) and ?type=. POST /deliveries/:id/redeliver sends one again within a few minutes, with the same delivery_id and a fresh signature: for one that failed while your app was down.

{ "deliveries": [{ "id": "...", "type": "reply.completed", "state": "failed", "attempts": 6,
  "last_status": 500, "last_error": "...", "created_at": "...", "sent_at": null,
  "next_attempt_at": "...", "invite_id": "..." }] }

Sends {type: "webhook.test", delivery_id, sent_at} to your app's webhook address now, signed like every other, and tells you what it answered. It isn't kept or retried. ok is true for a 2xx; a 401 usually means your route's secret isn't the app's signing secret, or it parsed the body before checking it. The address has to be a public https name.

{ "ok": true, "status": 200, "answer": "{"ok":true}", "error": null,
  "url": "https://acme.com/api/blip/webhook", "ms": 184 }