# big itsjustbig is the monetization platform for creators and small businesses: DM automation, lead forms, short links and link-in-bio that turn followers into revenue. ## What big is big is a growth platform for creators and businesses. It answers Instagram comments and DMs automatically, runs branching forms, and shares trackable short links. Every lead it captures lands in a contact list the creator owns. ## Status Anyone can sign up for big today: sign in with Google at https://itsjustbig.com/login and you get a free workspace on the teeny plan, at $0. Connecting an Instagram account to big is waiting on Meta's App Review, so a new workspace cannot run an Instagram DM automation yet. ## Pricing Prices are in USD. Every plan includes the core tools — auto-replies, forms, links and contacts. Plans differ in volume, and the one add-on (CLI and MCP access) is listed per plan. - **teeny** — free. 1 Instagram connection, 10 active automations, 100 automation steps per week, 250 MiB file storage. No CLI or MCP access. - **tiny** — $10/month (or $82.80/year). 2 Instagram connections, unlimited active automations, 1,000 automation steps per week, 5 GiB file storage. CLI and MCP access included. - **big** — $30/month (or $241.20/year). 3 Instagram connections, unlimited active automations, 10,000 automation steps per week, 25 GiB file storage. CLI and MCP access included. - **bigger** — $100/month (or $802.80/year). 5 Instagram connections, unlimited active automations, 100,000 automation steps per week, 100 GiB file storage. CLI and MCP access included. ## How it works - A follower comments on a post or sends a DM containing a keyword the creator chose. - big replies publicly and sends that person a DM with the creator's link. - The person becomes a contact the creator owns: name, conversation, source post, tags. - Comments that do not match a keyword are left alone. No keyword means no reply, no DM, and no spam. ## Services and Enterprise Beyond the self-serve plans, the big team offers Services: a fixed-fee audit of how a business captures and follows up with leads, then fixed-price build phases and an optional monthly retainer. big Enterprise is a private deployment of big hosted for one company with its own database. Both are priced per company after a strategy call, booked at https://itsjustbig.com/book. ## Compliance and safety - big sends every reply and DM through the official Instagram API from Meta. - big never asks for an Instagram password and never operates a bot that pretends to be the creator. - There is no scraping and no browser automation. ## Ownership Contacts captured through big belong to the creator, not to big. Followers belong to the platform; the contact list does not. ## Comparisons Sourced comparisons between big and other tools creators use. Every competitor claim lives on the page it belongs to, beside a public source URL and the date it was checked. Quote the page, not this list. - [big vs ManyChat](https://itsjustbig.com/vs/manychat) — checked 2026-09-10. big is one platform in which the DM automation, the trackable short link, the branching form and the contact record are the same product, so a reply that starts under an Instagram post ends as a contact row the creator owns without a handoff to a second tool. - [big vs Typeform](https://itsjustbig.com/vs/typeform) — checked 2026-09-29. A form in big is one station in a chain rather than a destination: the link that opens it is tracked, an Instagram DM automation can send people to it, and the answers land on a contact record the creator owns and can export. - [big vs Linktree](https://itsjustbig.com/vs/linktree) — checked 2026-09-29. In big the link page is one station in a chain that starts at an Instagram comment and ends at a contact the creator owns, not a page that stands on its own. ## Learn Task-focused articles on getting a specific result with big. Each one links to the documentation pages it relies on; the docs are the reference, these are the walkthroughs. - [How to build a conditional logic form](https://itsjustbig.com/learn/conditional-logic-form): Build a conditional logic form that shows questions based on earlier answers and sends each person to the right page, with big's visual editor. - [What is the Instagram 24 hour messaging window?](https://itsjustbig.com/learn/instagram-24-hour-messaging-window): The Instagram 24 hour messaging window decides when a business can DM someone: 24 hours after their last message, or 7 days after a comment. - [How to set up an Instagram comment auto DM](https://itsjustbig.com/learn/instagram-comment-auto-dm): Send an automatic DM to anyone who comments a keyword on your post: how to set up an Instagram comment auto DM in big and test it. - [How to track link in bio clicks, button by button](https://itsjustbig.com/learn/track-link-in-bio-clicks): Track link in bio clicks per button, see page views, and find which platform sent them, using a big link page and tagged short links. --- # big. docs > Source: https://itsjustbig.com/docs · Last modified: 2026-10-17T00:00:00.000Z Start with **[Get started with big](/docs/guides)** to build your first form, short link, or link page — or **[Automations](/docs/automations)** to put your Instagram comments and DMs on autopilot. Building against big? Read **[Plans](/docs/guides/account/plans#developer-access-cli-mcp-api)** first — the CLI, MCP servers, and API need a paid plan, and any paid plan covers both reads and writes. Want to point your own Claude at your workspace and ask it what's working? **[Analyze your workspace with your own Claude](/docs/developers/analyze-with-claude)**. New here? Anyone can **[sign in with Google](/login)** and start on the free teeny plan, and **[Pricing](/pricing)** lists what each plan costs before you pick one. Every page here has a markdown twin: append `.md` to any docs URL, or read the whole corpus at [/llms.txt](/llms.txt) and [/llms-full.txt](/llms-full.txt). --- # Work with the 24-hour window > Source: https://itsjustbig.com/docs/automations/24h-window · Last modified: 2026-09-09T00:00:00.000Z Instagram won't let you DM someone whenever you like. Each conversation has a **messaging window**, and an automated DM can only send while that window is open. Here's how the windows work so your replies always land. ## The two windows * **24-hour DM window.** When someone sends you a DM, a 24-hour window opens. You can send automated replies any time inside it. **Every new message from that person re-anchors the window** — the clock restarts from their latest message, so an active back-and-forth stays open. A reply to one of your stories counts here: Instagram delivers it as a DM, so it opens the same 24-hour window and re-anchors it like any other message. * **7-day comment window.** When someone comments on your post, you have **7 days** to send them a DM in response to that comment. ## What "expired" means If the window closes before your DM sends — the person stopped replying and 24 hours passed, or 7 days elapsed since the comment — the send is **expired**. big marks that automation run as expired and stops trying. It does not queue the message to fire later, because Instagram would reject it. See **[Run statuses](/docs/automations/run-status)** for how `expired` relates to the other four. ## How to stay inside the window * **Reply fast.** Automations fire within moments of the trigger, so you're normally well inside the window — this matters most if a send was delayed (for example by a plan cap). * **Design opt-ins around fresh activity.** A comment-to-DM automation on a new post fires while the 7-day window is wide open. * **Don't expect to reach cold conversations.** big can't reopen a window that has expired; the person has to message or comment again first. ## Next step If a DM didn't arrive, check whether the window had expired in **["Why didn't my automation fire?"](/docs/automations/why-didnt-fire)**. --- # Write an automation as steps > Source: https://itsjustbig.com/docs/automations/authoring · Last modified: 2026-09-29T00:00:00.000Z The dashboard builds automations as a canvas of connected bricks. That canvas is stored as a **node graph**, and for a long time the only way to make one programmatically was to hand-assemble it — inventing internal ids, wiring edges between them, numbering branch arms, and supplying canvas coordinates that the builder recomputes anyway. A **step document** is the same automation written as a list of steps. It is what `POST /api/automations` and `PUT /api/automations/:id/graph` accept as `document`, what the CLI's `rule:create` sends, and what an AI assistant connected over MCP writes. ## The shape ```json { "format": "big.automation/v1", "name": "Follow first → DM your link", "trigger": { "type": "dm", "keywords": ["VIP"] }, "steps": [ { "id": "ask", "dm": "Follow me and I'll send the link over. Reply once you have." }, { "id": "check", "branch": { "max_attempts": 2, "arms": [ { "when": "is_follower", "goto": "link" }, { "when": "otherwise", "goto": "nudge" }, { "when": "loop_exhausted", "goto": "letgo" } ] }} ], "paths": { "link": [{ "dm": "You're in. Here's the link: https://example.com" }], "nudge": [{ "dm": "I can't see the follow yet — reply again and I'll look.", "goto": "check" }], "letgo": [{ "dm": "All good, no hard feelings." }] } } ``` That is the whole follower gate: ask, check, send or nudge, and give up gracefully. **You rarely need to start from nothing.** Every automation in the **[template library](/docs/automations/templates)** is a document like this one: `big rule:template --document` prints one, and `GET /api/automation-templates/:id` returns it as `document`. ## The trigger `trigger.type` is `dm`, `comment` or `story_reply`, and `keywords` is the list of words that set it off. A `dm` or `story_reply` trigger with no keywords answers every message of that kind. A `comment` trigger needs at least one keyword — there is no catch-all for comments. `case_sensitive` is optional, and `skip_story_replies` is for a `dm` trigger only. **[Triggers](/docs/automations/triggers)** has the matching rules for each. A comment trigger watches one or more of your posts, and **the posts are not in the document**. Send them beside it on the request as `post_ids`, the Instagram media ids that `big posts` shows as `media:`. big works out which connected account each post belongs to, so `post_connection_ids` is optional. A media id big hasn't synced is refused with a message telling you to run `big posts:sync` first. ```json { "format": "big.automation/v1", "name": "Comment a word → DM your link", "trigger": { "type": "comment", "keywords": ["LINK"] }, "steps": [ { "id": "public-reply", "reply": "Sent it to your DMs 📩" }, { "id": "send-link", "dm": "Here's the link you asked for: https://example.com" } ] } ``` ## Steps and paths **`steps` is the spine.** Each step flows into the next one, so a plain keyword → DM automation is two steps and no wiring at all. The last step ends the conversation. **`paths` are named blocks**, reached only by name — from a branch arm or an explicit `goto`. Each path runs top to bottom and then stops, unless its last step carries a `goto`. **A branch ends the spine.** Everything after a branch is reached through its arms, never by falling through. **The split between the two is deliberate.** With one flat list, a step that sends your link and a step that says "I can't see the follow yet" would be connected just because one was written above the other — and that automation would be accepted as valid. Naming the blocks means the document says where someone goes, rather than implying it from the order you happened to type things in. ## Steps A step does exactly one thing: | Key | What it does | | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | `dm` | Sends a direct message. Add `link` to attach a URL. | | `branch` | Waits for their next reply and routes on it. | | `reply` | Replies publicly under the comment that fired the automation. Comment triggers only, and it must be `steps[0]`. Text only: no `link`, no `choices`. | And takes these modifiers: | Key | Where | What it does | | --------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | `id` | required in `steps` | The name other steps aim at. Not used in `paths` — the path's own name is its entry. | | `goto` | any step | Go here instead of falling through. | | `choices` | on a `dm` | Quick-reply buttons: `[{ "label": "✅ Done", "goto": "check" }]`. A step with buttons waits for a tap. Not on a comment trigger. | **A comment automation sends text only.** Its DMs are plain messages, so a `choices` anywhere in a comment document is refused rather than accepted and silently dropped. Keep it to a `reply` and a DM or two, sent within Instagram's **[7-day comment window](/docs/automations/24h-window#the-two-windows)**. ## Branch arms Arms are tried in the order you write them: | `when` | Matches | | ---------------- | ---------------------------------------------------- | | `contains_any` | Their reply contains any of `values` | | `equals` | Their reply is exactly `value` | | `is_follower` | They follow your account — checked live, right then | | `loop_exhausted` | The re-check ran out of tries | | `otherwise` | Everything else — **every branch needs exactly one** | `max_attempts` on a branch makes it a bounded loop: an arm can point back at the branch to re-check, and `loop_exhausted` is where someone lands when the tries run out. See **[Branch on replies and followers](/docs/automations/branches)** for what that feels like to the person on the other end. ## When something is wrong You get back the message the dashboard would show, naming **your** step: ``` branch node check closes a loop but its "after N tries" (loop_exhausted) edge doesn't leave it ``` The step names you choose are the names in the errors, so there is nothing to translate. ## How many steps one can have `max_actions_per_run` is optional and defaults to 20. It is also the **node ceiling** — an automation may not have more steps than the actions one run is allowed — and it may not be set above **20**, which is also the most the database stores. The same bound applies to `max_actions_per_run` on `POST` and `PATCH /api/automations`; anything outside 1–20 is a **400**. Each step's settings may be at most **16 KiB** of JSON. ## Reading one back `GET /api/automations/:id` returns the automation's `document` alongside its raw graph, so you can read one, change a message, and send it back. Comment automations read back too: the public reply comes back as a `reply` step, and the posts it watches come back on the `automation` row as `post_ids`, never inside the document. Some automations can't be written as steps. Cards, carousels and media attachments have shapes the format doesn't cover, and that includes a comment reply with media attached. Those come back with `document: null`, `exact: false`, and a `documentReason` saying which shape it was. The graph is always there either way. ## What it deliberately leaves out **Anything specific to one workspace**: which Instagram account the automation runs on, which posts a comment trigger watches, which tags it applies. A document is meant to be saved in a file, shared, and run in someone else's workspace — so those stay as separate fields on the request: `connection_id`, `post_ids`, `include_tag_ids` and `exclude_tag_ids`. That's why a comment document is portable even though a comment automation isn't: the same document runs on whichever post you name when you create it. The remote MCP server can't list your posts, so it refuses comment documents and links you to the dashboard instead. The CLI (`--post`) and the local MCP server (`postIds`) can create them. ## Next step **[The REST API reference](/docs/developers/api-reference#automations)** has the endpoints, and **[the CLI reference](/docs/developers/cli/command-reference#automations)** has `rule:templates`, `rule:template`, `rule:create`, `rule:graph` and `rule:view`. --- # Branch on replies and followers > Source: https://itsjustbig.com/docs/automations/branches · Last modified: 2026-09-30T00:00:00.000Z An automation doesn't have to be one straight line. A **branch** step waits for the person's next reply and routes them down a different path depending on what it says — or on whether they follow you. ## How a branch waits When the run reaches a branch, it pauses and waits for the person to reply. Their next message picks the path: * Each branch arm has a condition like *reply contains any of: "yes", "sure", "ok"*. The first arm that matches wins, checked in the order you arranged them. * Reply matching here is **contains**, not whole-word or exact — "yes please!" matches an arm keyed on `yes`. That's looser than trigger matching on purpose: people answer branches in sentences. * Every branch also has an **otherwise** arm. A reply that matches nothing takes it, so the run never gets stuck on an unexpected answer. Buttons and quick-reply chips work with branches too: a tapped button can jump the run straight to any step, including a branch. See **[Sending DMs](/docs/automations/sending-dms)** for the message formats that carry buttons. ## The follower check A branch arm can also test **does this person follow you?** When the run reaches it, big asks Instagram for the person's live follow status and routes accordingly — follower one way, non-follower the other. If the check can't complete (Instagram doesn't answer in time, say), the run takes the **otherwise** arm rather than stalling. Design that arm so it reads fine for someone whose status you couldn't confirm. ## The re-check loop The classic use: "Follow me, then tap ✅ when you're done." A follower-check branch can loop back to itself — the person taps, big re-checks, and if they still haven't followed, asks again. Loops are always bounded. You set how many times the branch checks (**Check up to N times** — the first check counts), and the builder requires an exit for when the checks run out (**After N checks, if they still don't follow, go here**). Once every check is spent, their **next** reply gets **one last look**: if they follow by then, they take the follower arm and get the link; if they don't, they come down the exit. At 2, someone who doesn't follow gets two checks and two nudges, and their third reply gets that last look before it takes the way out. Give the exit a graceful message that tells them to try again tomorrow: an automation answers each person at most once a day, so sending the keyword again straight away won't restart it. The last look is for the follower check only. A loop whose arms read the reply's words doesn't read it a final time — once its checks are spent, the next reply goes straight down the exit. **You already have a working one.** A new workspace is seeded with a paused **"Example: follow first → DM your link"** in **Automations** — open it and the four pieces are laid out: the ask, the follower arm, the otherwise arm looping back, and the **After N checks** way out. It is easier to change one that works than to wire the loop from scratch, and the validator is strict about this shape. (Workspaces created before September 2026 won't have it; the pieces above are the whole recipe.) ## Reading the canvas The canvas draws each kind of connection differently, and a small legend in its top-left corner names the ones this automation uses: * **Solid black line** — the next step. big does it straight away. * **Solid black line with a black label** — a branch arm. Their reply (or whether they follow you) decides which one they take. * **Dashed orange line with a pill label** — a tap. *They* chose it by tapping a chip or button. See **[Choices on the canvas](/docs/automations/sending-dms#choices-on-the-canvas)**. * **Line up the right-hand side with a ↺** — goes back and asks again. In the follower gate it runs from the nudge back to the check. * **Red dashed stub marked Not connected** — a choice that doesn't go to any step yet. Save refuses it. A branch reads their reply; a tap is their choice. Both can send people down different paths, but only a branch looks at what they typed or at their account. The first time a branch or a set of choices is on your canvas, Dot walks you through it, and again the first time you open a Send DM or Branch panel. **Show me around** in a panel's header replays that panel's walkthrough. ## Things worth knowing * While a run is parked at a branch, new messages from that person **continue the run** — they won't start a different automation until this one finishes or expires. * A branch reply still has to arrive inside the [messaging window](/docs/automations/24h-window). If the person goes quiet past the window, the run expires where it stands. * The follower check costs a live Instagram lookup, so it happens only when the person actually reaches that branch. ## Building one without the canvas A branched flow is fiddly to click together and easy to write down. **[Write an automation as steps](/docs/automations/authoring)** is the same follower gate as a short document you can hand to the CLI, the API, or an AI assistant — and `big rule:template dm-follower-gate --document` prints a working one to start from. In the dashboard, the same gate is the **Follow first → DM your link** card in the **[template library](/docs/automations/templates)**. ## Next step If a branched flow ever seems stuck, **["Why didn't my automation fire?"](/docs/automations/why-didnt-fire)** covers the wait-and-window cases. --- # Build your first automation > Source: https://itsjustbig.com/docs/automations/build-first · Last modified: 2026-09-29T00:00:00.000Z By the end of this page you'll have a live automation that DMs anyone who comments a keyword on your post. Your list isn't empty to start with: a new workspace already holds two paused **Example** automations — a plain keyword → DM, and a follower gate. You can edit the plain one instead of starting fresh — **[The example we left you](/docs/automations#the-example-we-left-you)** — or leave it alone and follow the steps below. Those two and six more ready-made automations are in the **[template library](/docs/automations/templates)**, which is where **New automation** starts. **Prefer not to click?** The same automation can be written as a short document and sent from the terminal or by an AI assistant — see **[Write an automation as steps](/docs/automations/authoring)**. Everything below is the dashboard route. ## Steps 1. In big, click **New automation**. It opens the template library. 2. **Pick Comment a word → DM your link.** It opens on the canvas with a comment trigger on the keyword `LINK`, a public reply, and a DM, all already written. It starts **paused**, so nothing sends while you edit it. 3. **Bind the post.** The trigger card says **No post bound**. Click it and pick the post (or reel) you want to watch. The automation won't save without one. 4. **Set the keyword.** Keep `LINK` or type the word people will comment. big matches the whole word, so a comment of `link` or `Send me the LINK` will fire, but `linkup` will not. See **[Triggers](/docs/automations/triggers)** for the exact matching rules. 5. **Edit the public reply.** The **Reply to comment** step answers under their comment so they know to check their inbox. Change "Sent it to your DMs 📩" if you like. 6. **Write the DM.** The **Send a DM** step carries an `https://example.com` placeholder. Replace it with your link or call to action. 7. **Turn it on and save.** Switch the automation on at the top of the canvas, then press **Save**. ### From scratch instead Pick **Start from scratch** in step 1 to get a blank canvas with only the trigger card. Choose **Comment on a post** and select the post, set the keyword, click **Send a DM** and write your message, and optionally add **Reply to comment**. (The other two triggers — an incoming DM, and a reply to one of your stories — need no target: they watch the whole account. See **[Triggers](/docs/automations/triggers)**.) Then turn it on and save. ## Test it Comment your keyword on the post from a different Instagram account. Within a few moments you should see the DM arrive and, if you added one, the public reply. One thing to know before you test twice: each account can trigger a given automation only **once every 24 hours**. If you comment again from the same test account to double-check, nothing happens — that's the per-contact cooldown, not a bug. Use a second account or wait it out. ## It didn't fire? Don't worry — there are a few common reasons (the keyword didn't match exactly, the messaging window had closed, or you hit your plan cap). Walk through **["Why didn't my automation fire?"](/docs/automations/why-didnt-fire)**. ## Next step Learn how matching works in **[Triggers](/docs/automations/triggers)**. --- # Connect your Instagram account > Source: https://itsjustbig.com/docs/automations/connect-instagram · Last modified: 2026-10-01T00:00:00.000Z When you finish this page, big will be authorized to read comments on your posts and send DMs from your account. ## What you need * A **professional Instagram account** — Business or Creator (not Personal). That's it — big connects with **Instagram Login**, so you sign in with Instagram directly. You do **not** need a linked Facebook Page. If your account is still Personal, switch it in the Instagram app under **Settings → Account type and tools → Switch to professional account** before continuing. ## Connect 1. Open big and click **Connect Instagram**. 2. You'll be sent to Instagram to approve access. Sign in with the account you want to automate. 3. Approve the permissions big asks for — reading your profile and posts, reading and replying to comments, and sending messages. big can't post to your feed, follow accounts, or change your profile. 4. You'll land back in big with your account showing as **Connected**. ## How many accounts can I connect? Your workspace can hold several Instagram connections, up to the limit of your plan. See **[Limits & plans](/docs/guides/account/plans)** for the per-plan caps. If you're already at your plan's cap, the connect step is blocked until you upgrade or remove an existing connection. ## If the connection fails * Make sure the account is **professional** (Business or Creator), not Personal. * Make sure you're signing in as the owner of the account you want to automate. * Confirm you're not already at your plan's connection cap. * Finish in the **same browser** you started in, within about 10 minutes. A connect link only works once and only in the browser that clicked **Connect Instagram**, so you can't send the Instagram approval link to someone else to approve on their device. Ask them to join your workspace as an admin and connect it themselves instead. * If you see "already connected to another workspace", that Instagram account is active in a different big workspace. Disconnect it there first. * Re-run **Connect Instagram** — re-approving the permissions usually clears a stuck connection. ## Next step You're connected. Now **[build your first automation](/docs/automations/build-first)**. --- # Understand automations > Source: https://itsjustbig.com/docs/automations · Last modified: 2026-09-29T00:00:00.000Z An automation is one rule: **when this happens, do that.** A trigger watches your Instagram, and when it matches, big runs the actions you connected to it. First time here? Press **Show me around** in the corner of the Automations screen for a guided, in-app walkthrough — it covers the same ground as this page, pointed at the real controls. ## The shape of an automation Every automation is a small graph that starts with a **trigger** and flows into one or more **actions**: * **Trigger** — what big watches for. Today that's a comment on one of your posts, an incoming DM, or a reply to one of your stories. * **Actions** — what big does in response: * **Send a DM** — message the person directly. * **Reply to the comment** — post a public reply under their comment. * **Branch** — take a different path depending on the situation, so one automation can handle several outcomes. A branch can route on **what the person said** (whether their reply contains certain words) or on **whether they follow you**. You can also build a bounded "ask them to follow, then re-check" loop with a limit on how many times it retries. A trigger flows into a send-DM, a reply-comment, or a branch; a branch then flows into its own actions. You build this visually — there's nothing to write. ## A simple example > **When** someone comments `LINK` on my latest reel > **then** reply to the comment with "Check your DMs!" > **and** send them a DM with my link. That's two actions hanging off one comment trigger. ## The example we left you **The first two cards in a new workspace's Automations list are ours.** The first is called **"Example: keyword → DM your link"** and it carries an **Example** chip: a DM trigger on the keyword `LINK` with one send-DM action hanging off it — the smallest automation that still has a shape worth reading. It does nothing as it stands, deliberately. It is **switched off**, and no Instagram account is picked for it, so there is nothing for it to watch and nowhere for it to send. A paused automation also spends none of your **[active-automation cap](/docs/guides/account/plans#automations-limits)**. Turning it into a real one is four edits: 1. **Change the keyword.** Open the card and replace `LINK` with the word you want people to send you. **[Triggers](/docs/automations/triggers)** has the matching rules. 2. **Write the DM.** Replace the placeholder message with your actual link or offer. **[Sending DMs](/docs/automations/sending-dms)** covers what you can and can't put in one. 3. **Pick the connection.** Choose which **[connected Instagram account](/docs/automations/connect-instagram)** it watches. Until you do, it has none. 4. **Switch it on.** It starts watching at that point, and starts counting toward the cap. It's a DM trigger rather than a comment one because a comment automation has to name the posts it watches before it will save, and we can't know which of your posts you meant. Want it to watch a post's comments instead? Change the trigger and pick the post, as in **[Build your first automation](/docs/automations/build-first)**. **Or delete it.** It's yours, deleting it is permanent, and nothing puts it back — see **[Your example automation and form](/docs/guides#your-example-automation-and-form)**. **Both Examples are also in the template library**, as `dm-keyword-link` and `dm-follower-gate`, beside six more starting points. Deleting an Example card doesn't remove it from the library: click **New automation** and pick it again. See **[Start from a template](/docs/automations/templates)**. ### The second one: a follower gate Under it sits **"Example: follow first → DM your link"**, also paused, also carrying an **Example** chip. It is the flow people ask us for most: *follow me and I'll send you the link.* It is a DM trigger on `VIP`, and it has four pieces worth opening the card to see: 1. **The ask.** A DM telling them to follow and reply when they have. 2. **The follower arm.** A **[branch](/docs/automations/branches)** whose first arm tests *follows your account* — a live check against Instagram at that moment — and sends the link when it passes. 3. **The otherwise arm.** Where a non-follower goes, and it loops **back** to the check, so their next reply is checked again. 4. **The way out.** An **after N tries** arm, set to 2, so nobody is asked forever. It sends a friendly sign-off and does **not** hand over the link — a gate whose exit gives the thing away isn't a gate. Making it yours is the same shape as above — change the keyword, write the three messages, pick the connection, switch it on — plus one decision the first example doesn't have: **how many re-checks you'll allow** before letting someone go. Two honest notes. If Instagram can't confirm the follow, the run takes the otherwise arm, so a real follower can occasionally be asked again; that's why the message says we can't *see* the follow rather than accusing them. And if your offer was never really gated, point the **after N tries** arm at the link step instead — one dropdown, and the nagging stops mattering. ## Where to go next * **[Build your first automation](/docs/automations/build-first)** — a step-by-step walkthrough. * **[Start from a template](/docs/automations/templates)** — pick a ready-made keyword, follower-gate, comment or FAQ automation and change the words. * **[Triggers](/docs/automations/triggers)** — how comment, DM, and story-reply matching works. * **[Sending DMs](/docs/automations/sending-dms)** — what you can and can't send. * **[The 24-hour window](/docs/automations/24h-window)** — the timing rule that decides whether a DM can go out. * **[Write an automation as steps](/docs/automations/authoring)** — build one from a short document instead of the canvas, for the CLI, the API, or an AI assistant. * **[Run statuses](/docs/automations/run-status)** — what `active`, `awaiting_reply`, `completed`, `expired`, and `halted` mean. * **[Manage posts & comments](/docs/automations/posts)** — moderate the comments on the posts your automations watch. * **[The inbox](/docs/inbox)** — read and reply to the DMs your automations generate. * **[How we compare](/vs)** — sourced, dated comparisons with the other DM automation tools, if you're weighing a move from one. --- # Manage posts & comments > Source: https://itsjustbig.com/docs/automations/posts · Last modified: 2026-09-14T00:00:00.000Z Under **Manage → Posts** you can browse your connected Instagram account's posts and moderate the comments on them — reply, hide, or delete — without leaving big. It needs a [connected Instagram account](/docs/automations/connect-instagram); without one, you'll see a prompt to connect. ## Browsing posts The Posts tab shows your recent posts as cards (thumbnail, caption, likes, comment count, date). big refreshes them from Instagram when you open the tab — they're at most a few minutes stale — and shows the most recent posts first. Use the **search box** to find older posts by caption; search covers your full synced history, not just the posts on screen. If a refresh can't reach Instagram, big shows your last cached posts with a small banner rather than an error. ## Moderating comments Select a post to see its comments. Three actions are available, and each one takes effect **on Instagram itself** — this isn't a local view: * **Reply** — posts a **public** reply under the comment (not a DM). * **Hide / Unhide** — hides the comment on Instagram. Reversible. * **Delete** — permanently removes the comment from Instagram. Not reversible. All three require an **editor** role or higher. Viewers can read comments but not moderate them. ## "Pending review" vs. "reconnect" If comment tools show a **pending Instagram's review** message, that means the underlying permission hasn't been approved by Meta yet — reconnecting your account won't change it. That's different from a **reconnect** prompt, which means your access expired and re-connecting will fix it. ## How this relates to comment automations Managing comments here is **manual moderation** — it's separate from [comment-trigger automations](/docs/automations/triggers), which watch a post and reply automatically. Acting on a comment here doesn't change your automations, and vice versa. Both act on the same posts, so they work well together: let an automation handle the keyword replies, and step in by hand for everything else. ## The rest of the Manage tab **Manage** also holds **[Tags](/docs/inbox/tags)** and your **[Whitelist](/docs/automations/whitelist)**. --- # Run statuses > Source: https://itsjustbig.com/docs/automations/run-status · Last modified: 2026-10-02T00:00:00.000Z A **run** is one contact's journey through one automation. Every time a trigger matches a person who doesn't already have a run open, big creates one and walks it through the automation's graph. `big runs ` and `GET /api/automations/:id/runs` print each run's **status**; here's what the five values mean. To look at one run — its status, the node it is parked on, how many actions it took, and when it last heard from the contact — run `big run:view ` (or `GET /api/runs/:id`, or `big_run_get` over MCP) with an id from that list. ## The five statuses | Status | Open? | Means | | ---------------- | ----- | ------------------------------------------------------------------------------------------- | | `active` | yes | The run is working — walking the graph and queueing sends. | | `awaiting_reply` | yes | The run is parked at a branch, waiting for the contact's next DM to decide which way to go. | | `completed` | no | It reached the end of the graph. Nothing more will happen. | | `expired` | no | The messaging window closed before it finished. | | `halted` | no | A safety guard stopped it. | The three terminal statuses are final: a run never leaves them, and a new trigger from the same person mints a fresh run rather than reviving the old one. ## `awaiting_reply` is the one to understand When an automation branches on **what the person says**, the run can't continue until they say something. It parks in `awaiting_reply`, remembers which branch node it's sitting on, and waits. Their next inbound DM resumes it from exactly that point. This matters because of the **one-open-run-per-contact** rule: a contact can have at most one open run per connected account, and `active` and `awaiting_reply` both count as open. So while a run is parked waiting for a reply, the contact's next DM **continues that conversation** rather than starting a different automation — even if their message would have matched another automation's keyword perfectly. The same holds for a comment: a matching comment from someone mid-conversation is skipped rather than starting a second run, and once their open run's window has closed the comment starts its automation as normal. That's usually the answer to "why did my other automation not fire for this person?" — see **[Fix an automation that didn't fire](/docs/automations/why-didnt-fire#9-another-automation-fired-first)**. ## `expired` Instagram only lets you DM someone inside an open window — 24 hours from their last DM, 7 days from their comment. If the window closes before the run finishes, the run is marked `expired` and stops. big does not queue the remaining messages for later, because Instagram would reject them. The window is re-anchored by every new message from that person, so an active back-and-forth stays open. See **[The 24-hour window](/docs/automations/24h-window)**. ## `halted` `halted` means big stopped the run deliberately, as a guard rather than an outcome. The common causes: * **The run hit its step limit.** Each automation has a maximum number of actions per run; a run that reaches it stops instead of continuing. * **The weekly plan cap blocked a new run from starting.** A conversation already in flight is allowed to finish, but a run that can't take its first step is halted rather than left hanging. This includes the week *after* you go over the cap: a backlog of locked form responses is released before any automation runs, so the new week's budget can be spent before your automations get any of it. See **[Plans](/docs/guides/account/plans#the-weekly-usage-cap)** and **[cause 6](/docs/automations/why-didnt-fire#6-a-backlog-of-locked-form-responses-is-spending-the-new-weeks-budget)**. * **A follower re-check loop ran out of attempts** with no "still not following" path to route into. * **The automation was deleted or its graph became unwalkable** while the run was open. * **A reply couldn't be queued for sending.** big stops the run there instead of skipping ahead, and that step is not counted against your weekly usage. A halted run is not a bug report on its own — the step limit and the plan cap are working as designed. A halt you can't account for is worth reporting. ## `completed` The run walked to the end of its graph. Note that "completed" describes the *run*, not delivery: a message can be queued successfully and still fail on its way to Instagram. If a run reads `completed` but nothing arrived, check the send queue — **[cause 13](/docs/automations/why-didnt-fire#13-the-send-was-queued-and-gave-up)**. ## Look at one run `big run:view ` prints one run in full: ```text run_1 [awaiting_reply] automation: … contact: … connection: … current node: the branch it is parked on (— once it ends) actions: 2 started: … last inbound: the contact's last DM into this run last advanced: the last step it took expires: when the messaging window closes ``` `last inbound` against `expires` is usually the answer to "why did this contact stop getting replies": an `awaiting_reply` run whose contact never wrote back runs out its window and becomes `expired`. The run's `context` — what the contact typed into it — appears only with `--json`. It needs `automations:read`. --- # Send DMs that actually deliver > Source: https://itsjustbig.com/docs/automations/sending-dms · Last modified: 2026-09-30T00:00:00.000Z A DM only goes out if Instagram's messaging rules allow it. Miss those rules and the reply is silently dropped, so they're worth two minutes of your time. ## What a DM action can contain A send-DM action can be any of these message formats: * **Text** — a plain message with your link or call to action. * **Card** — an image with a title, subtitle, and one or more buttons. * **Carousel** — a swipeable row of cards. * **Quick replies** — a text message with tappable chips the person can pick from. A card button can either **open a URL** or **move the automation** to a step. A quick-reply chip always moves the automation to a step — chips can't open a link, so put a link in the message text or use a card button (and a tapped choice can [branch the flow](/docs/automations/branches)). A DM action can also attach **media** you've uploaded to [Files](/docs/guides/files) — note that a text caption plus an attachment arrives as **two messages**, the text first and the file right behind it. A DM action runs as a reply triggered by a comment, or as a reply to an incoming DM. Keep it conversational — you're answering someone who just raised their hand. ## Choices on the canvas Quick-reply chips and card buttons show up on their Send DM card as pills, in the order they're sent. Each choice that moves the automation has a **dashed orange line** from the card down to the step it opens, labelled with the choice's text, so you can follow any tap to its answer. A line that goes back to an earlier step runs up the right-hand side with a **↺** on it. A link button shows **↗** and has no line, because it leaves the automation. The legend in the top-left corner of the canvas names each kind of line that appears in this automation. * **Add a choice in the card's panel.** Open the Send DM card, and each choice has a **Go to step** list. Pick **+ New step…** to give that choice a brand-new step of its own, or point it at a step that's already there. Up to 13 chips, 20 characters each. * **A choice that goes nowhere is flagged.** If its step was deleted or never picked, the card shows **Not connected** under it, and **Save** refuses the automation until you point it somewhere or remove it. * **No "+" under a step that waits for a tap.** Once a DM sends choices, the run waits there for a tap — there is no "next step" to add under it. Add what should happen under each choice's own step instead. * **Typing instead of tapping gets the choices once more.** If the person types a reply instead of tapping, no path is picked — big sends the same message with its choices again and keeps waiting for a tap. If they type a second time, the conversation ends there and nothing more is sent, so make each label say exactly what they'll get. The repeat counts as a send like any other: it uses your weekly sending allowance and one of the automation's steps. (An older automation may have a step hung straight under a chip card; that line is labelled **TYPED INSTEAD**, and a typed reply goes down it instead of getting the choices again.) * **Comment automations send text only**, so their choices are drawn struck through and never sent. ## The rule that decides delivery: the messaging window Instagram only lets you send a DM inside an open **messaging window**: * **Comment-triggered DMs** can be sent within **7 days** of the person's comment. * **DM conversations** open a **24-hour window** that re-anchors each time the person messages you again. As long as they keep replying, the window keeps reopening. * Once the window has **expired**, the send can't go out and the automation run is marked expired — big won't keep retrying against a closed window. The full timing picture is on **[The 24-hour window](/docs/automations/24h-window)**. ## Why a DM might not send * The messaging window has closed (most common). * The recipient's account can't receive automated messages. * You've hit your plan's weekly sending cap, which blocks **new** conversations from starting (ones already mid-flow finish) — see **[Limits & plans](/docs/guides/account/plans)**. * Your workspace has been **[suspended](/docs/guides/account/suspended)**, which pauses new automation runs and holds queued sends until it is lifted. If a send didn't happen, **["Why didn't my automation fire?"](/docs/automations/why-didnt-fire)** walks through each cause. ## Next step Read **[The 24-hour window](/docs/automations/24h-window)** so your replies always land inside an open window. --- # Start from a template > Source: https://itsjustbig.com/docs/automations/templates · Last modified: 2026-09-30T00:00:00.000Z Most automations people build are one of a handful of shapes: a keyword that gets your link, a follow-first gate, a comment that turns into a DM. The template library has each of those already wired. You pick one, change the words and the link, and switch it on. A template is an ordinary **[step document](/docs/automations/authoring)**, so the same library is open to the dashboard, the CLI, the REST API and an AI assistant connected over MCP. ## Pick one In big, click **New automation**. Instead of an empty canvas you get the library: * **Start from scratch** comes first. It opens a blank canvas with only the trigger card, switched **off** like every template. * Then every template, grouped into **Grow your audience**, **Sell and capture leads** and **Answer questions**. Each card shows its trigger, the keyword it waits for, how many steps it has, and **needs a post** if it's a comment template. Click a card and it opens on the canvas with every step already written. You can link straight to one, too: `/automations/new?template=` opens that template, with the ids from the table below. A link to an id that isn't in the library opens the picker with a notice instead. First time here? Press **Show me around** in the corner and Dot walks you through the picker: what the trigger chip means, the comment-to-DM template, the templates that ask with buttons, the scratch card, and why everything starts paused. Once a template is open, Dot also explains tap choices and branches the first time they're on your canvas, and each panel (Send DM, Branch) the first time you open it. You need the editor role or higher to create an automation. ## What's in the library The **Trigger** column says what sets it off, and the **Keyword** column is the word it starts with. A DM or story-reply keyword must be the whole message, and a comment keyword only has to appear as a word in the comment (see **[Triggers](/docs/automations/triggers)**). "Any" means the trigger has no keyword and answers every message of that kind. ### Grow your audience | Id | Name | Trigger | Keyword | What it does | What to change | | ------------------------ | -------------------------------- | ----------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- | | `dm-keyword-link` | Keyword → DM your link | DM | `LINK` | Someone DMs you a word and gets your link straight back. | The keyword, the link. | | `dm-follower-gate` | Follow first → DM your link | DM | `VIP` | Asks them to follow, checks that they did, then sends the link. A non-follower is nudged and checked again; it checks up to two times, and the reply after that gets one last look — a follower gets the link, anyone else is let go without it. | The keyword, the three messages, the link, how many checks (`max_attempts`). | | `comment-keyword-link` | Comment a word → DM your link | Comment | `LINK` | Replies publicly under the comment, then DMs them the link. | The post, the keyword, the public reply, the link. | | `comment-giveaway-entry` | Giveaway entry by comment | Comment | `WIN` | Confirms the entry publicly, then DMs the draw date and your rules. | The post, the keyword, the draw date, your rules link. | | `story-reply-thanks` | Story reply → thank-you and link | Story reply | Any | Thanks anyone who replies to one of your stories and sends your link. | The message, the link, and keywords if you only want to answer some replies. | ### Sell and capture leads | Id | Name | Trigger | Keyword | What it does | What to change | | ------------------- | ------------------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------- | | `dm-lead-qualifier` | Qualify a lead with a tap | DM | `START` | Asks what they're after with three tappable choices (**Free guide**, **Work with me**, **Just looking**) and sends each answer somewhere different. The choices show as pills on the first DM, each with its own line to its answer. | The keyword, the three choices, each path's link. A form you built in big works well behind **Work with me**. | ### Answer questions | Id | Name | Trigger | Keyword | What it does | What to change | | ------------- | -------------------- | ------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | `dm-faq-menu` | FAQ menu | DM | `FAQ`, `HELP` | A menu of your common questions (**Prices**, **Shipping**, **Talk to a human**). Each tap sends the answer, and the last one tells them you'll reply yourself. | The keywords, the topics (up to 13 — **+ New step…** in a choice's **Go to step** list adds the answer for a new one), each answer. | | `dm-welcome` | Welcome every new DM | DM | Any | An instant hello to any DM your keyword automations don't answer, with your link. It skips story replies, so a story automation can answer those. | The message, the link. | **`dm-welcome` answers every DM no keyword automation claims.** Only one automation runs per message, and at the same priority an automation with keywords is tried before one without — so your keyword automations keep their messages whether you add the welcome first or last. See **[Which automation answers](/docs/automations/triggers#which-automation-answers)** for how priority is decided. The two automations a new workspace is seeded with, the **Example** cards on your Automations list, are `dm-keyword-link` and `dm-follower-gate`. See **[The example we left you](/docs/automations#the-example-we-left-you)**. ## Every template starts paused A template opens switched **off**, and so does **Start from scratch**. Every link in it points at `https://example.com`, and some messages carry a marker like `[DATE — edit this]`, so a template nobody edited would answer your fans with a placeholder. Starting paused means saving it by accident answers nobody. To make one live: 1. Change the keyword, if you want a different word. 2. Rewrite each message and replace every `example.com` link with yours. 3. For a comment template, bind the post (below). 4. Switch it on at the top of the canvas and press **Save**. Test it from a second account. Each person can set an automation off once a day, so a second try from the same account within 24 hours gets no answer. A paused automation doesn't count toward your **[active-automation cap](/docs/guides/account/plans#automations-limits)**. It starts counting when you switch it on. ## Comment templates need a post `comment-keyword-link` and `comment-giveaway-entry` watch the comments on one of your posts, and a template can't know which one you mean. They open with **No post bound** on the trigger card. Click it and pick the post or reel. The automation won't save until a post is bound. Two rules come with comment automations: * **One active comment automation per post.** If another active automation already watches that post, saving fails until you switch the other one off. See **[Triggers](/docs/automations/triggers#comment-triggers)**. * **Text only.** A comment automation sends a public reply and plain DMs. There are no tappable choices, and its DM goes out within Instagram's **[7-day comment window](/docs/automations/24h-window#the-two-windows)**. That's why both comment templates are two steps: the reply, then one DM. The picker lists the posts big has synced. If a new post isn't there yet, open the Posts tab (see **[Manage posts & comments](/docs/automations/posts#browsing-posts)**), which refreshes them from Instagram. ## Build one with an agent The library is the same from the terminal and from an AI assistant. The flow is always: list the templates, read one's document, rewrite its keywords, messages and links from what you want, then create it. What gets created is **paused**, so you read it back and switch it on yourself. ### From the CLI Say you want anyone who comments `GUIDE` on your latest reel to get your free guide. Start with the comment template: ```bash big rule:templates --trigger comment big rule:template comment-keyword-link --document > guide.json ``` Edit `guide.json`. Change the keyword, the reply and the link, and keep the step ids: ```json { "format": "big.automation/v1", "name": "Comment GUIDE → DM the guide", "trigger": { "type": "comment", "keywords": ["GUIDE"] }, "steps": [ { "id": "public-reply", "reply": "Sent it to your DMs 📩" }, { "id": "send-link", "dm": "Here's the free guide 👉 https://yourname.example/guide" } ] } ``` The post isn't in the document. Find its Instagram media id with `big posts`, where each row shows `media:`, and pass it with `--post`: ```bash big posts big rule:create "Comment GUIDE" --steps guide.json --template comment-keyword-link --post 17912345678901234 big rule:view --steps big rule:toggle --on ``` * `--template` with `--steps` creates your edited document and records which template it came from. * `--template` on its own creates the template exactly as written, `example.com` links included, and the CLI warns you to edit it. * A comment document without `--post` is refused before anything is sent. Repeat `--post` to watch more than one post. * `rule:create` makes a paused automation unless you pass `--active`. `big rule:example` still works but is deprecated. It now prints a template's document, and its old names map to `dm-follower-gate` (`follower-gate`) and `dm-keyword-link` (`keyword-reply`). Use `big rule:template --document` instead. Every flag is in the **[CLI reference](/docs/developers/cli/command-reference#automations)**. ### From an AI assistant Tell your assistant what you want in plain words, for example: *"Set up an automation so anyone who DMs me VIP has to follow me first, then gets my link, [https://yourname.example/vip](https://yourname.example/vip)."* With the **[MCP server](/docs/developers/mcp)** connected, it should: 1. List the library and pick `dm-follower-gate`. 2. Read that template's document. 3. Rewrite the keyword, the three messages and the `example.com` link from what you said, and ask you for anything in the template's "what to change" list it doesn't know. 4. Create it with the edited document and the template id. 5. Tell you it's paused, so you can read it back and switch it on. | Step | Local server (`big mcp`) | Remote server (`/api/mcp`) | | -------- | ------------------------------------------------------- | -------------------------------------------------------- | | List | `big_rule_templates_list` (`category`, `triggerType`) | `list_automation_templates` (`category`, `trigger_type`) | | Read one | `big_rule_template_view` (`templateId`) | `get_automation_template` (`template_id`) | | Create | `big_rule_create` (`document`, `templateId`, `postIds`) | `create_automation` (`document`, `template_id`) | `category` is `grow`, `sell` or `support`, and the trigger filter is `dm`, `comment` or `story_reply`. **Comment templates on the remote server go to the dashboard.** The remote server can't list your posts, so `create_automation` refuses a comment document, creates nothing, and returns a link to `/automations/new?template=` where you pick the post and finish it on the canvas. The local server can create one: the assistant finds the post with `big_posts_list` and passes its `ig_media_id` in `postIds`. `big_rule_create` also starts paused unless the assistant asks for `active: true`, and that needs `confirm: true` too. `create_automation` is always paused. ### Over the REST API `GET /api/automation-templates` lists the library, and `GET /api/automation-templates/:id` returns one template with its `document`. Create it with `POST /api/automations`, sending your edited `document`, the `template_id`, and for a comment document the `post_ids`. Over REST an automation is created **active** unless you send `"active": false`. Details are in the **[API reference](/docs/developers/api-reference#automation-templates)**. ## Next step Want to see every step by hand? **[Build your first automation](/docs/automations/build-first)** walks through a comment-to-DM automation on the canvas. --- # Choose the right trigger > Source: https://itsjustbig.com/docs/automations/triggers · Last modified: 2026-09-30T00:00:00.000Z A trigger decides whether an automation fires. Pick the one that matches how people reach you, and set its keywords so it catches the right messages and skips the wrong ones. You can give a trigger **more than one keyword** — enter them as a comma-separated list, and the trigger fires when an incoming message matches **any** of them. ## Comment triggers A comment trigger watches a specific post or reel and fires when someone comments one of your keywords. * **Matching is whole-word.** big looks for your keyword as a standalone word in the comment. `LINK` fires on "LINK", "send me the link please", and "Link?" — but **not** on "linktree" or "blinking", because the keyword isn't a separate word there. * **Case-insensitive by default.** `LINK`, `link`, and `Link` all match — unless you turn on **Case sensitive** for the trigger (see below). * **A comment trigger needs a post and at least one keyword** — there's no catch-all for comments. * **One active comment automation per post.** If another active automation already watches the same post, saving a second one fails until you deactivate the first. * Use a short, distinctive keyword so you don't fire on unrelated chatter. ## DM triggers A DM trigger fires when someone sends your account a direct message. * **Matching is exact.** The incoming DM must equal one of your keywords. A DM trigger keyed on `START` fires when the message is "START", but **not** when it's "I want to START" — that's extra text around the keyword. * **Case-insensitive by default**, unless you turn on **Case sensitive**. * **Leave the keywords empty to make a catch-all.** A DM trigger with no keywords fires on *any* incoming DM. The automation card shows it as "any DM arrives". Use it for a general welcome flow — your keyword automations still win their own words, whichever you created first (see **[Which automation answers](#which-automation-answers)**). * Use keyword DM triggers for clean, single-word opt-ins where you tell people exactly what to send. * **A reply to your story is a DM too**, so DM triggers match those as well — see **[Story replies and your DM automations](#story-replies-and-your-dm-automations)** below. ## Story-reply triggers When someone replies to one of your Instagram stories, Instagram delivers that reply to you as an ordinary direct message. A **story-reply** trigger fires on those messages specifically, so a fan who replies `YES` to your story can get a different answer from someone who types `YES` into your inbox cold. * **It watches every story on the account, not one story.** There's no story picker like the one comment triggers have for posts, and there won't be one: a story disappears after 24 hours, so a trigger bound to a single story would be dead by tomorrow. Choose the account the automation runs on, and it covers whatever you post to it. * **Keywords are optional.** Leave them empty and the trigger fires on *any* story reply — the automation card shows it as "any story reply arrives". Add keywords and it fires only when the reply matches one of them. * **Matching is exact**, the same rule DM triggers use. A story trigger keyed on `YES` fires when the reply is "YES", but **not** when it's "yes send it please". * **Case-insensitive by default**, unless you turn on **Case sensitive**. * **Nothing to switch on.** Story replies come in over the same connection your DMs already use. If your Instagram account is connected, story triggers work — there's no extra permission to grant and no reconnecting to do. ### Story replies and your DM automations **Your existing DM automations keep answering story replies.** Because a story reply *is* a DM, a catch-all DM trigger still fires on one exactly as it did before story triggers existed — the promise that a keyword-less DM trigger fires on any incoming DM is unchanged, and it always covered story replies. Adding a story automation doesn't take that away. If you'd rather your story replies were handled *only* by a story automation, turn on **Skip story replies** on the DM trigger. It's off by default, so no automation you already built changed behaviour. It governs which automation **starts**: if someone is already mid-conversation with that DM automation, a story reply from them continues that conversation, exactly as any other reply of theirs would. When a story reply could match both a DM automation and a story automation, the usual rule decides (see **[Which automation answers](#which-automation-answers)**). A story automation **with keywords** beats a catch-all DM automation on those keywords. But two catch-alls — a keyword-less DM trigger and a keyword-less story trigger — tie, and the **older** one answers, so a catch-all DM automation you already had will beat a catch-all story automation you add today. **Turn on Skip story replies on that DM trigger** and the story automation wins. ## Which automation answers Only **one** automation runs per incoming message. When more than one matches, big picks in this order: 1. **Priority order** — a lower `priority_order` goes first. Automations you build in the dashboard all share the same priority; it's only settable over the API, via `priority_order` on [`PATCH /api/automations/:id`](/docs/developers/api-reference#automations) — there's no reorder control in the dashboard yet. 2. **Keywords before catch-alls** — at the same priority, an automation with keywords is tried before one without, so a catch-all welcome never steals a keyword's message, however old it is. 3. **Oldest first** — anything still tied goes to the automation created first. An explicit priority still wins over everything else: a catch-all you give a lower `priority_order` answers before any keyword automation behind it. ## Case sensitivity By default, matching ignores letter case. Each trigger has an optional **Case sensitive** setting in the automation builder — turn it on when case matters, and `LINK` will then match `LINK` but **not** `link`. It's off by default, so unless you change it, case never matters. ## The three triggers at a glance | | Comment trigger | DM trigger | Story-reply trigger | | -------------- | -------------------------------------- | ------------------------------------------------------ | ----------------------------------------------------------------------- | | Watches | A chosen post/reel | Your inbox | Every story on the account | | Keywords | One or more required (any match fires) | One or more (any match fires), or none for a catch-all | One or more (any match fires), or none for a catch-all | | Matching | Whole word anywhere in the comment | Exact match of the whole message | Exact match of the whole message | | Case sensitive | Optional — off by default | Optional — off by default | Optional — off by default | | Pick a target | Yes — one post or reel | No | No — a story expires in 24 hours, so there's nothing durable to bind to | ## Tags applied on trigger A trigger can carry a list of [tags](/docs/inbox/tags). Anyone who fires the automation gets those tags added to their contact automatically — handy for building an audience out of everyone who commented `LINK`, without tagging by hand. ## Next step Once your trigger fires, big runs your actions. See **[Sending DMs](/docs/automations/sending-dms)** for what those replies can contain and when they're allowed to go out. To route people down different paths based on how they reply, see **[Branches](/docs/automations/branches)**. --- # Whitelist people from automations > Source: https://itsjustbig.com/docs/automations/whitelist · Last modified: 2026-09-09T00:00:00.000Z The **whitelist** is a per-workspace list of people your automations should leave alone. It's useful for teammates, your own alt accounts, VIPs you'd rather reply to by hand, or anyone you don't want auto-messaged. Manage it under **Manage → Whitelist**. ## What it does When someone is on the whitelist, their comments and DMs **never start a new automation run**. Their messages still arrive and show up in your inbox as normal — big just won't auto-reply to them. You can suppress each channel independently: * **Skip DMs** — don't run DM automations for this person. This covers **story-reply** automations as well: a reply to your story arrives as a DM, so it's the DM channel that's suppressed. * **Skip comments** — don't run comment automations for this person. Turn on one or both. An automation that's already mid-conversation with someone will finish; the whitelist only stops *new* runs from starting. ## Add someone * **By handle** — enter their Instagram `@handle` in **Manage → Whitelist**. * **From the inbox** — choosing **Ignore** on a contact also adds them to the whitelist, so automations stop firing for them. Adding to the whitelist requires an editor role or higher. --- # Fix an automation that didn't fire > Source: https://itsjustbig.com/docs/automations/why-didnt-fire · Last modified: 2026-10-01T00:00:00.000Z Walk this list top to bottom — the causes are ordered from most to least common. Each one tells you exactly what to check. ## 1. The automation is turned off Open the automation and confirm it's set to **Active**. A draft or paused automation never fires. ## 2. The keyword didn't match Matching is stricter than it looks: * **Comment triggers** match the keyword as a **whole word**. `LINK` won't fire on "linktree". * **DM triggers** match the **whole message exactly**. `START` won't fire on "I want to start". * **Story-reply triggers** match the whole reply exactly too. `YES` won't fire on "yes please". And if you meant the automation to answer *every* reply to your stories, clear its keywords — a story trigger with keywords only fires on those keywords. Re-read **[Triggers](/docs/automations/triggers)** and test with a comment or DM that matches precisely. Case only matters if you turned on the trigger's **Case sensitive** setting — otherwise it's ignored. ## 3. You tested twice with the same account Each contact can trigger a given automation only **once every 24 hours**. If you commented your keyword, got the DM, then commented again from the same account to double-check, the second attempt is silently skipped — that's the cooldown working, not the automation breaking. It only blocks *starting* the automation again; a conversation already in progress keeps going. Test again from a different account, or wait out the 24 hours. ## 4. The messaging window had expired A DM can only send inside an open window — **24 hours** from the person's last DM, or **7 days** from their comment. If too much time passed, the run is marked **expired** and won't send. This is the most common reason a "working" automation goes quiet on older conversations. See **[The 24-hour window](/docs/automations/24h-window)**. ## 5. You hit a plan cap Each plan has a weekly cap on automation sends **and form submissions together**, so a busy form can use up the same budget your DMs draw on. Once you reach it, **new** conversations stop starting until the week resets or you upgrade — though a conversation already mid-flow is allowed to finish, so you may still see some replies go out after hitting the cap. Check **[Limits & plans](/docs/guides/account/plans)** and your current usage. ## 6. A backlog of locked form responses is spending the new week's budget This is the one that surprises people, because it looks like the cap didn't actually reset. Form submissions are never refused. When you go over the weekly cap, the responses that arrive after it are still stored, but they're stored **locked** — you can see they came in, not what they say. At the weekly reset those locked responses unlock, oldest first, and **unlocking is served before any automation.** So the new week's budget is spent on clearing the backlog first, and your automations only start firing again once it's cleared. The consequence: if you locked 900 responses on a plan with a 1,000 cap, Monday's reset spends almost the whole week's budget releasing them and your automations stay quiet for most of the week. If you're locking more responses per week than your cap covers, the backlog never clears on its own and your automations stay quiet indefinitely. Two ways out: **upgrade**, which unlocks the entire backlog immediately and frees the week's budget for automations, or reduce what's coming in (see the anti-spam notes in **[Share your form](/docs/guides/forms/sharing#anti-spam)** if the volume is junk). Your locked count is on **[Settings → Billing](/docs/guides/account/billing)** and on each form's responses page. ## 7. The contact is excluded by an audience rule Automations skip a contact when an **[audience rule](/docs/inbox/tags)** says to. This happens if the contact holds a tag you've set to *exclude from automations*, or if the automation uses an *include* allowlist and the contact isn't on it. Open the automation's trigger settings and the contact's tags to check. If big can't read the contact's tags at that moment, it skips the contact rather than risk messaging someone you excluded. The next message from them is checked again. ## 8. The contact is whitelisted Contacts on your **[whitelist](/docs/automations/whitelist)** are skipped by every automation. **Skip DMs** covers story-reply automations too, since a story reply is a DM. If you (or an "ignore contact" action in the inbox) added them, automations won't fire for them. Check **Manage → Whitelist**. ## 9. Another automation fired first Only **one** automation runs per incoming message — the first one that matches, in your automations' priority order, with keyword automations tried before catch-alls at the same priority. And if the contact already has an open conversation with one automation, a new inbound DM continues that conversation instead of starting a different automation. A matching **comment** from them doesn't start a comment automation either until that conversation ends or its window closes. If you expected a *different* automation to fire, this is usually why. **This is the usual answer for a story automation that stayed quiet.** A reply to your story arrives as an ordinary DM, so a catch-all DM automation matches it as well — and if that DM automation sits higher in your priority order, it wins and your story automation never runs. **The fix is Skip story replies:** open the DM trigger and turn it on, so that automation leaves story replies to the story automation. It's off by default. A story automation with keywords already wins its keywords over a catch-all DM automation, but two catch-alls tie and the older one answers, so the DM catch-all you already had wins — and priority order is only settable over the API (`priority_order` on `PATCH /api/automations/:id`). See **[Which automation answers](/docs/automations/triggers#which-automation-answers)**. If it's the other way round — a DM automation that used to answer story replies and now doesn't — someone turned that setting on. See **[Triggers](/docs/automations/triggers#story-replies-and-your-dm-automations)**. ## 10. Automations are suspended for being over your connection cap If your workspace stays over its Instagram-connection cap past the grace period, automated replies are suspended until you get back under the cap (or upgrade). Check **[Connections](/docs/automations/connect-instagram)** and your plan. ## 11. Your workspace is suspended If big has suspended your workspace, no new automation run starts and nothing new leaves the send queue — for every automation and every connected account at once. That is different from cause 10 above: the connection cap is a state you clear yourself by getting back under it, while a suspension is applied by a person and lifted by one. The workspace owner is notified with the reason when it happens, so check the bell and the owner's email. See **[If your workspace is suspended](/docs/guides/account/suspended)**. ## 12. The Instagram connection needs reconnecting If the connection shows an error or expired state, re-run **[Connect Instagram](/docs/automations/connect-instagram)** to re-authorize. When Instagram or Facebook revokes big's access, big marks the account **expired**, stops its automations, and notifies the workspace owner in the bell and by email, so you hear about it before your followers do. ## 13. You tested with your own account Instagram won't deliver an automated DM from your account to itself. Test from a **different** Instagram account. ## 14. The send was queued and gave up The first thirteen causes all stop a send *before* it's attempted. This one is different: the automation matched, the run started, big accepted the message — and it still never arrived. That's the **send queue**. Every outgoing DM goes onto a durable queue rather than straight out to Instagram, so a hiccup on Instagram's side doesn't lose the message. A queued send is in one of three states: | State | Means | | ------------- | ----------------------------------------------------------- | | `pending` | Waiting for its turn, or waiting out a retry delay. | | `sending` | A worker has claimed it and is calling Instagram right now. | | `dead_letter` | It gave up. This message will never be sent. | **A successful send leaves no row at all** — the queue entry is deleted and the message itself becomes the record. So an *empty* queue is the healthy state. Anything sitting in the queue is either in flight or stuck. A send that Instagram **answered** with an error retries with a growing delay (never more than 15 minutes between attempts) and dead-letters after 5 failed attempts. It also dead-letters immediately, without spending attempts, when retrying is pointless or unsafe: * **the send got no answer** — the request left big but timed out or was cut off, so it may already have reached the person. big never sends it a second time; it is dead-lettered as `send_unanswered`, and the rest of the conversation carries on; * **the Instagram connection isn't usable** — disconnected, deauthorized, expired, or its stored token can't be decrypted (this one means "reconnect the account"); * **the 24-hour window closed while the message waited** — big won't send into a closed window, so a message that sat in backoff too long is dropped rather than rejected by Instagram. See **[The 24-hour window](/docs/automations/24h-window)**; * **an earlier step in the same conversation dead-lettered** — the chain is broken, so the steps after it are stopped rather than sent out of order. Two things follow from this that are easy to misread: * **A one-step automation that dead-letters looks identical to one that never fired.** Nothing arrives, and the run itself may still read as `active`. Check the run's status against **[Run statuses](/docs/automations/run-status)** before assuming the trigger didn't match. * **A multi-step automation can deliver its first message and nothing after it.** That's the chain-halt rule above, not a broken graph. Queue state is per connection, on the Connect page — and readable programmatically at `GET /api/connections/:id/send-queue`, which returns the pending and dead-letter counts plus the most recent failures with their error codes. The companion `GET /api/connections/:id/health` shows the two flags that stop sends without any other signal, `send_backoff_until` and `auto_reply_suspended`. See **[Connection diagnostics](/docs/developers/api-reference#connection-diagnostics)**. Dead-letter rows are swept after a retention period, so investigate a silent failure while it's recent. ## Working this list from the CLI or an AI client Everything above is readable without opening the dashboard, which matters when you've handed the question to an agent. Three surfaces expose the same data under different names — the `big` CLI, the local MCP server (`big mcp`, tools prefixed `big_`), and the remote MCP server (unprefixed tools). Pick the column you're connected to: | To check | CLI | Local MCP | Remote MCP | | ----------------------------------------------------------------- | ---------------------------- | ----------------------- | ----------------------- | | Everything at once — start here (causes 5, 6, 10, 11, 12) | `big stats` | `big_workspace_stats` | `workspace_stats` | | Whether an automation is on, and when it last fired (causes 1, 9) | `big stats:automations` | `big_automations_stats` | `automation_stats` | | What a specific run actually did (causes 4, 14) | `big runs ` | `big_runs_list` | — | | Backoff and suspension flags (causes 10, 11) | `big connection:health ` | `big_connection_health` | `connection_health` | | Pending and dead-lettered sends (cause 14) | `big connection:queue ` | `big_send_queue` | `connection_send_queue` | | Who automations never fire for (cause 8) | `big whitelist` | `big_whitelist_list` | — | | Tag rules that exclude a contact (cause 7) | `big tags` | `big_tags_list` | `list_tags` | Start with the one-call rollup. It needs no scope and answers causes 5, 6, 10, 11 and 12 together, so it rules out five of the fourteen before you ask a second question. Two things no surface here will tell you. **Keyword matching (cause 2) can only be judged by reading the automation's keywords against the exact text that was sent** — no tool replays a match. And the **Activity feed**, which lists inbound events as *matched* or *no match*, is dashboard-only: if the rollup and the runs both look healthy and you still can't tell whether the message ever reached a trigger, open **Activity** in the app. An agent that has ruled out the fourteen causes above should say that rather than keep guessing. ## Still stuck? If you've ruled out all of the above and the automation still won't fire, reach out to support with the post or conversation and roughly when you expected it to run. --- # Files > Source: https://itsjustbig.com/docs/guides/files · Last modified: 2026-07-21T00:00:00.000Z **Files** is your workspace's media store. Upload an image or file once, and it's available to send in automations and inbox replies. Open it from **Files** in the sidebar. ## Upload and manage * **Editors and above** can upload and delete files. * **Viewers** see the list read-only. Each file shows its name, type, and size. Deleting a file frees up the storage it used. ## Storage allowance Every plan includes a storage allowance, and your uploads count against it: * **teeny** — 250 MiB * **tiny** — 5 GiB * **big** — 25 GiB * **bigger** — 100 GiB When you're out of space, new uploads are blocked until you delete something or upgrade. See **[Plans](/docs/guides/account/plans)** for the full comparison. ## Using a file in a message If you use big's Instagram DM features, uploaded files can be attached to the messages big sends: add one as media on a send-DM [automation](/docs/automations) action. Attaching a file to a reply you type by hand is not available — [manual replying is coming soon](/docs/inbox#reply-by-hand--coming-soon), so `big inbox send --media ` is refused too. --- # Get started with big. > Source: https://itsjustbig.com/docs/guides · Last modified: 2026-10-17T00:00:00.000Z big lets you collect responses and track clicks without connecting anything. Sign up, create a form or a link, and share it. Responses and clicks show up on your dashboard as they happen. Don't have an account yet? **[Sign in with Google](/login)** and you get a free workspace on the teeny plan. ## What you can do right now * **Forms** — build a public form, share its link, and collect structured responses in a table inside big. * **Short links** — create a short, trackable redirect and see clicks, referrers, and device breakdowns for it. * **Link pages** — build one hosted link-in-bio page at `/t/` that holds all of the above as buttons. None of them requires connecting an Instagram account. Automations (below) are the only feature that does. Most screens also offer a **Show me around** button (bottom-right corner) that walks you through that feature in place — a fast way to learn one without leaving it for the manual. The tour on **Activity** — the screen you land on when you sign in — is the one that covers more than a single feature: it reads the hub, explains the **Matched** and **No match** filters, and points out the sidebar itself, because the hub only boxes the surfaces that produce numbers. Files, Manage and Settings never get a box, so the sidebar is the full list of where things live. On a phone that sidebar becomes the bottom tab bar, and the rooms that don't fit a slot sit under **Menu**. **Want the welcome again?** Open **Settings → Account** and choose **replay onboarding**. Dot walks you through the first-login questions again with fresh answers. Leave **Also replay the guided tours** ticked and every tour plays again the first time you open its page; untick it to replay only the welcome. Anyone on a workspace can do this, and it only changes your own onboarding, not your teammates'. **[Short links](/docs/guides/links)** and **[link pages](/docs/guides/trees)** sit side by side under **Links** in the sidebar: a short link is one redirect at `/l/`, a link page is one hosted page at `/t/` holding many buttons — and each button on a link page gets its own short link, so its clicks are counted. ## Your example automation and form **A new workspace isn't empty.** We put two example automations and one example form in it, so the first-run tour has something real to point at and you have something to open and take apart instead of a blank list and a **New** button. * **"Example: keyword → DM your link"** sits in **Automations**. It's a DM trigger on the keyword `LINK` that sends one DM back. It ships **paused**, with no Instagram account picked — so it watches nothing and sends nothing as it stands. Because it's paused it doesn't count toward your **[active-automation cap](/docs/guides/account/plans#automations-limits)** either. **[Understand automations](/docs/automations#the-example-we-left-you)** walks through turning it into a real one. * **"Example: follow first → DM your link"** sits under it, and it's the one worth opening even if you never use it. It's a DM trigger on the keyword `VIP` that asks the person to follow you, waits for their reply, checks whether they actually did, and sends the link only if so — checking up to twice before letting them go politely. That's a **[follower check and a bounded re-check loop](/docs/automations/branches)** already wired correctly, which is fiddly to build from scratch. Paused, like the other one. * **"Example: which link do you want?"** sits in **Forms**. It's a **draft** with two pages and a real fork: one answer on page 1 sends the respondent to a follow-up page, everyone else goes straight to submit. That's **[conditional logic](/docs/guides/forms/logic)** working, before you've built any. A draft has no live public page and accepts no submissions until you publish it. Both carry an **Example** chip so you can always tell ours from yours. The chip stays after you rename or edit one — it means "this started as our example", not "you haven't touched this yet". The chip isn't only a dashboard thing: the same provenance is `source: "template"` on the API, the CLI (`big forms` and `big rules` print `(example)` after the row) and both MCP servers, so a script or an AI agent reporting on your workspace can tell our example from your work without guessing at the title. **Delete either one whenever you like, and it stays deleted.** A workspace is stocked once and only once; nothing refills it, so a deleted example never reappears — and there's no undo, so delete it because you don't want it, not to see what happens. Deleting both just leaves the ordinary empty lists, and nothing nags you about it. **[Delete a form](/docs/guides/forms#delete-a-form)** covers the form half; an automation deletes from its own card. Two details worth knowing if your workspace isn't brand new: * **Existing workspaces get them too, one list at a time.** If your Automations list or your Forms list is empty, the matching example turns up there. Each list is looked at on its own, so a workspace with three forms and no automations gets the example automations and no second form. * **A workspace is stocked once, so examples added later don't turn up in it.** The follower-gate example above ships to workspaces created from September 2026 on. If yours already had the keyword example, you won't find a second one — building it yourself is **[Branch on replies and followers](/docs/automations/branches)**, and that page now points at the same four pieces. * **If Automations isn't in your nav yet**, you'll only see the form for now. The automation is waiting for you and appears in the list once the feature is switched on for your workspace. The guided tour — the dot in the corner, **Show me around** — anchors its steps on these. If you delete them before taking the tour, it still runs, with fewer stops. ## Create your first form 1. Sign up and open **Forms** in big. 2. Give it a title and add a few fields. 3. Set its status to **active** — only active forms accept submissions. 4. Share the public link (`/f/:slug`) anywhere. See **[Forms](/docs/guides/forms)** for field types, sharing, and validation details. ## Create your first link 1. Open **Links → Short links** in the sidebar. 2. Paste the URL you want to redirect to. 3. Optionally pick a custom alias instead of a random code. 4. Share the short link (`/l/:code`). See **[Short Links](/docs/guides/links)** for how creating and sharing a link works. ## Create your first link page 1. Open **Links** in the sidebar and choose **New link page**. 2. Claim a handle — it becomes `itsjustbig.com/t/`. 3. Add link, form, socials, image, and header blocks; pick a theme. 4. Publish. Until you do, the page 404s for everyone. See **[Link pages](/docs/guides/trees)** for blocks, theming, handles, and stats. ## See your results Both features show results live in the dashboard — no export needed to get started: * Form submissions land in the **[responses table](/docs/guides/forms/responses)**. * Link clicks show up in **[link stats](/docs/guides/links/stats)**, broken down by period, referrer, and device. ## Instagram automations Automations auto-reply to Instagram DMs and comments — a separate feature from forms and links, so you don't need them to use anything above, but they're available to every workspace now, not just a select few. The only thing you need beyond an account is a [connected Instagram account](/docs/automations/connect-instagram). Start at [Understand automations](/docs/automations), or open **Automations** in the sidebar and press **Show me around**. --- # Billing > Source: https://itsjustbig.com/docs/guides/account/billing · Last modified: 2026-09-30T00:00:00.000Z Billing lives in one place: **Settings → Billing**. ## Who can change it Only the **workspace owner** can start a checkout, switch plans, or open the billing portal. Admins and editors can open the page and read the current plan, but see a read-only notice instead of the controls. See **[Team & roles](/docs/guides/account/team)**. ## What the page shows * **Current plan** — the tier you're on, the subscription status, and either the renewal date or, if you've cancelled, the date access ends. * **Weekly usage** — automation steps *and form submissions* used this week against your plan's cap; the two share one budget. Over the cap the number keeps climbing past it (you'll see something like `340/100`) rather than stopping, because that overage is real work already done. The cap and the reset (00:00 UTC Monday) are covered in **[Plans](/docs/guides/account/plans)**. Crossing 80% and 100% notifies the workspace owner — the bell in the header and an email; see **[Notifications](/docs/guides/account/notifications)**. * **Locked responses** — how many form responses arrived after the cap and are stored but not yet readable. They unlock oldest first at the weekly reset, ahead of your automations; upgrading unlocks all of them at once. See **[Forms](/docs/guides/forms#limits)**. * **Plan cards** — every tier with its price, connection allowance, active-automation allowance, weekly usage cap, and whether the CLI/MCP is available (read + write on every paid plan) or unavailable. * **Recent billing activity** — payments, invoices, and plan changes, once you've had a subscription. A workspace that has never had one shows nothing here. ## Monthly or annual Each plan is offered per month or billed annually at a lower monthly-equivalent rate. Toggle the period on the plan cards before starting checkout. Current prices are on **[Plans](/docs/guides/account/plans)**, but the checkout page is the authoritative number. ## Changing plan Choosing a tier sends you to Stripe Checkout. Once you already have a subscription, use **Manage billing** to open the Stripe customer portal, where you can change plan, update your card, download invoices, or cancel. See **[If checkout doesn't open](#if-checkout-doesnt-open)** for what repeat clicks do. ## When a payment fails If a renewal is declined, or your bank wants an extra 3D Secure confirmation before it will go through, the workspace owner gets a **[notification](/docs/guides/account/notifications)** and an email — once per invoice, not once per retry. Both point back here, where **Manage billing** opens the Stripe portal to pay the invoice or update the card. Your plan stays active meanwhile, but only for **3 days** from the first failed payment: if the renewal is still unpaid after that, the workspace drops to **teeny** (free) even while Stripe keeps retrying the card. Paying the invoice restores your plan straight away. A first payment that fails at checkout never unlocks the paid plan at all. ## Cancelling Cancelling doesn't take effect immediately. You keep your current plan until the end of the billing period, then drop to **teeny** (free). Until that date the page shows a "cancels on …" notice, and you can reactivate from **Manage billing** at any point before it. For what is and is not refundable, the 14-day window on a first payment, and statutory withdrawal rights in the EEA and UK, see the **[Refund & cancellation policy](/refund-policy)**. Dropping to teeny changes what's available: teeny has no CLI/MCP/API access at all, allows one Instagram connection, caps active automations at 10, and shows the "Powered by big." footer on public forms. ## If checkout doesn't open A checkout page stays open for about 30 minutes. Choosing the same tier again in that time takes you back to the same checkout page rather than a second one, so a workspace can't end up paying for two subscriptions. Choosing a different tier closes the earlier page and opens a new one. If you see "a checkout for this workspace is already being prepared", wait a few seconds and try again. If Stripe is having trouble, checkout and **Manage billing** show "Billing is temporarily unavailable, try again in a minute". Nothing has been charged. Wait a minute and try again. ## Related * **[Plans](/docs/guides/account/plans)** — what each tier includes. * **[Your data](/docs/guides/account/your-data)** — exporting or deleting the account entirely. --- # Notifications > Source: https://itsjustbig.com/docs/guides/account/notifications · Last modified: 2026-10-17T00:00:00.000Z Every dashboard screen has a bell in its header. It shows how many notifications you haven't opened yet, and it is the one place to find what big has told you, whether or not you saw the email. ## The bell * **The count** is your unread notifications in the workspace you're in. It updates when you open the bell; there's no live polling, and nothing here needs a refresh to be accurate at the moment you look. * **Open a notification** to mark it read and go where it's about. A usage-cap notice, for example, takes you to **[Settings → Billing](/docs/guides/account/billing)**. A notification with nowhere to go is simply marked read. * **Mark all read** clears the count for this workspace. Read notifications stay in the list for a while (see below) and are simply no longer bold. ## Per workspace What you see follows the workspace you're in. If you belong to more than one, each workspace's notifications appear only while that workspace is active, so a count from one never bleeds into the other. Leave a workspace and its notifications leave with it; if you're added back, they return. ## What notifies you today * **The weekly usage cap** — when your workspace crosses **80%** of its cap, and again when it reaches **100%**, the workspace owner gets a notification. Once per threshold per week, and never a "you're approaching" notice for a workspace that has already hit it. See **[Plans](/docs/guides/account/plans#the-weekly-usage-cap)** for what the cap covers and what happens at 100%. * **A renewal that needs you** — the workspace owner is notified when a renewal payment fails, and when your bank asks for an extra confirmation (3D Secure) before it will go through. Once per invoice, not once per retry. Both open **[Settings → Billing](/docs/guides/account/billing)**, where **Manage billing** takes you to Stripe to pay the invoice or update your card. The confirmation one matters most: until you act, the renewal stays unpaid, and an unpaid renewal drops the workspace to the free tier 3 days after the payment first fails. * **A suspension** — if your workspace is suspended, the owner is notified with the reason, and gets the same message by email. It is the only place the reason appears, and it explains what a suspension pauses and what it leaves alone. See **[If your workspace is suspended](/docs/guides/account/suspended)**. * **A new form response**: each time someone submits one of your workspace's public forms, the workspace owner gets a notification, once per submission. It names the form and, when the form collects an email or Instagram handle, who sent it. The rest of their answers stay in big and are never put in the notice or the email. It opens that form's **[Responses](/docs/guides/forms/responses)** tab. A response stored locked because the workspace is past its weekly cap doesn't notify. Anything typed in that field that isn't a real email or handle is left out. A workspace gets at most 60 of these notices an hour; past that, responses are still stored and shown on the Responses tab, they just don't notify. * **An account that needs reconnecting**: when Instagram or Facebook stops accepting big's access to one of your connected accounts, the workspace owner gets a notification and an email. That happens when a message is refused because the account's access was revoked (a password change, or big removed from the account's app settings, are the usual causes), or when big can't renew the account's access before it runs out. From that moment the account shows as expired on **[Connect](/docs/automations/connect-instagram)**, automation replies on it stop, and nothing new is charged against your weekly cap for it. Messages already waiting to go out from that account are not sent. Once per expiry: reconnecting the account starts its automations again, and a later expiry notifies you again. It opens the Connect page. * **An integration that needs attention**: when a tool your workspace connected by signing in, stops accepting big's access, every admin of the workspace gets a notification and an email. That happens when big's access was revoked or its app removed in the tool. The integration shows **Reconnect needed** and big stops reading that tool until an admin reconnects it. The same kind tells admins when someone in another big workspace tried to connect an account this workspace already holds (at most once a day per integration). Once each time an integration needs reconnecting. It opens the integration's page. More kinds will land here as they ship; anything big tells you *about your workspace* will arrive through the same bell. The product-update email is the one thing that doesn't — it is a separate, opt-in channel and never appears here. See **[Product updates](/docs/guides/account/product-updates)**. ## Email Every notification is also sent by email to the same person, using the same words. The bell is the record: if an email doesn't arrive, the notification is still in the app, and nothing is lost — muting an email (below) doesn't change that either. If the send itself fails — big's email provider having a bad moment, say — it's tried again for about a week; after that, or as soon as you've muted the kind, it stops trying. An email you already got is never sent a second time. Two of the six kinds can be turned off; four can't: * **The weekly usage cap** always emails you, and there's no setting that stops it. At 100% your automation replies stop, and silence at that moment is exactly the failure this notice exists to prevent — a cap notice you could mute would defeat the point of having one. * **A suspension** always emails you too. A suspended workspace is the one situation where you may need to read what happened without signing in, the email is the only place the reason appears, and someone who has been locked out may simply never open the app again. * **An account that needs reconnecting** always emails you. Your automation replies on that account have stopped, and like the 100% cap notice, a quiet failure there is the thing the notice exists to prevent. * **An integration that needs attention** always emails you. big has stopped reading that tool, and nothing else will tell you until someone opens the integration. * **A renewal that needs you** can be turned off, with an exception inside it: the message asking your bank to confirm a payment (3D Secure) always sends even if you've muted the kind, because the renewal can't complete until you act on it. A declined-charge notice, where the state is already on your billing screen, respects the mute. * **A new form response** can be turned off, with no exception. A busy form sends one per submission, so this is the one most people quiet. Muting it stops the email and keeps the notification in the bell. An email for a kind you can mute carries an **Unsubscribe** link in its footer, and the message itself carries `List-Unsubscribe` headers so your mail client can offer one-click unsubscribe too. Following either turns off that one kind for the workspace the email was about — it needs no login, and the page it lands on says plainly that the notice still appears in the bell. The link is good for 400 days from when it was sent, so an old email keeps working. The usage-cap, suspension, reconnect and integration emails, being unmutable, carry no unsubscribe link or header at all. big does send one other kind of email — an occasional **product-update digest** — and it is a separate channel end to end: a separate list people joined through the waitlist before sign-up opened, a separate sender, and its own unsubscribe link. Unsubscribing from a digest changes nothing here, and muting an account notice above changes nothing about the digest. See **[Product updates](/docs/guides/account/product-updates)**. ## Choosing which emails you get **[Settings → Notifications](/settings?tab=notifications)** lists every notification kind with a checkbox, one row per kind, plus a read-only note about the product-update digest and where to manage it. It's scoped to the workspace you're in — muting a kind here only stops that email for that workspace; the same kind still emails you in a workspace you haven't muted it in. Unchecking a box stops the email and nothing else: the bell keeps getting written, same as always. The usage-cap, suspension, reconnect and integration rows have no checkbox — they're always on, for the reasons above. ## Retention Notifications you've opened are cleared once they're **90 days old** — the clock runs from when big sent it, not from when you opened it, so opening an old one doesn't extend it. Unread notifications are kept however old they get, until you open them. ## Dashboard only The bell and its feed are for the person in the app; there is no CLI, MCP, or API surface for them, and every plan gets them. A request made with a personal access token gets a **403** that says the endpoint is dashboard-only. Everything a notification reports — usage, billing state — is already readable on the surfaces those tokens can reach. Your email preferences are the one exception, and only for reading: a personal access token or MCP call can fetch which kinds are muted, so an agent can report your notification settings back to you. Changing them still needs the dashboard — a token can read the state but can't silence your account email. --- # Plans > Source: https://itsjustbig.com/docs/guides/account/plans · Last modified: 2026-10-18T00:00:00.000Z ## Forms and links are almost entirely uncapped There's **no per-plan limit on forms, fields, links, link-in-bio pages, or clicks — on any tier, including free.** Everyone sees full stats, whatever they pay. There is one flat ceiling, and it is the same on every plan: a workspace keeps at most **100 forms** and **100 link pages**. It bounds what you keep rather than what you do, and it is high enough that it only shows up on a workspace creating them from a script — creating one over the API or the CLI past 100 is refused, and from 70 the answer names the ones nothing has visited in the last 90 days so you know which to delete. The one exception is **form submissions**, which count against the **[weekly usage cap](#the-weekly-usage-cap)** below. Views, clicks, and the forms themselves are never capped — only a stored submission counts, and the counter resets every Monday. ## What does differ big has four plans: **teeny** (free), **tiny**, **big**, and **bigger**. The differences that matter for forms and links are: * **Branding.** On **teeny** (free), public forms show a "Powered by big." footer. Every paid plan (**tiny** and up) removes it. Automation DMs never carry big branding, on any plan — your reply goes out exactly as you wrote it. * **File storage.** Each plan includes a storage allowance for files: 250 MiB on teeny, 5 GiB on tiny, 25 GiB on big, and 100 GiB on bigger. This backs the Files feature, separate from forms and links themselves. * **Connected Instagram accounts.** Relevant once you use [automations](/docs/automations) (see below): 1 connection on teeny, 2 on tiny, 3 on big, 5 on bigger. * **Integrations.** How many of your other tools (Calendly, Discord and so on) a workspace can connect: 2 on teeny, 5 on tiny, 15 on big, 50 on bigger. This count is separate from connected Instagram and Facebook accounts, so connecting a tool never uses up a messaging slot. See **[Integration limits](#integration-limits)** below. Pricing: teeny is free; tiny is $10/mo (or $6.90/mo billed annually); big is $30/mo (or $20.10/mo billed annually); bigger is $100/mo (or $66.90/mo billed annually). See the **[pricing page](/pricing)** — or your billing page inside big, once you have an account — for the current, authoritative numbers. ## Developer access (CLI, MCP, API) This section is the single source of truth for what a plan buys you on the programmatic surface — the `big` CLI, both MCP servers, and the REST API. They share one entitlement, so a plan that can't read over the API can't read over MCP either. | Plan | CLI / MCP / API | | ---------------- | --------------------- | | **teeny** (free) | **No access at all.** | | **tiny** | Read **and** write. | | **big** | Read **and** write. | | **bigger** | Read **and** write. | The line is simply **free versus paid**: every paid plan gets the whole programmatic surface, reads and writes alike. There is no read-only paid tier. * **Read** means anything that only fetches — listing automations, contacts, forms, links, posts, reading DM threads, pulling stats. * **Write** means anything that changes something: creating a link, sending a DM, tagging a contact, publishing a form, syncing posts, deleting anything. Every write endpoint is identified by a `:write` scope. * A request your plan doesn't cover returns **402**, with a message pointing at your billing page — on today's plans that only happens on **teeny**. Authorization refusals are **403** instead — your token is missing a *scope*, your role is too low, the endpoint is dashboard-only and accepts no token at all (below), or the workspace has been [suspended](/docs/guides/account/suspended), which pauses the whole programmatic surface whatever the plan. The message tells you which. * **Publishing is not on that dashboard-only list, but it does need a person.** A token, a CLI command or an AI agent can *ask* to publish a link page or a form; it goes live only once someone signed into big approves the request in the browser, and the approval screen is session-only in exactly the way the governance surface is. No plan, scope or role changes that, and there is no publish scope to mint — see **[Approving a publish](/docs/guides/trees/publish#approving-a-publish-an-agent-or-the-cli-asked-for)**. * **The 100-forms and 100-link-pages ceiling** above is enforced here rather than in the dashboard: a create over the API or the CLI is refused past it, with a **403** you report rather than a 429 you retry. See **[Forms and links are almost entirely uncapped](#forms-and-links-are-almost-entirely-uncapped)**. * **On teeny, use the dashboard.** Everything the CLI and MCP can read is on screen already: automations under **Automations**, DMs under **Inbox**, contacts and tags under **Manage**, form responses and stats on each form, and click stats under **Links → Short links**. A paid plan is necessary but not sufficient: your token still needs the right **[scope](/docs/developers/authentication#scopes)**, and writes still need an editor role or higher. And while the CLI and API are in **beta**, the personal-access-token surface — the CLI, the local MCP server, and the REST API — also needs your workspace to be enrolled: an unenrolled workspace gets a **403** with `code: feature_disabled` on every call, whatever its plan. Ask a workspace owner to request access, or email [support@itsjustbig.com](mailto:support@itsjustbig.com). The remote MCP endpoint has no enrollment gate. ### One exception: reading the documentation The four documentation surfaces — `GET /api/search`, `/docs/.md`, `/llms.txt`, `/llms-full.txt`, and the `big docs:search` / `big docs:read` commands and `big_docs_search` / `big_docs_read` tools that wrap them — are **not** plan-gated. Any valid token reads them on any plan, free included, and they need no scope. Putting the manual behind the paywall it documents would be user-hostile, and reading documentation exposes no workspace data. On teeny, `big login` stores your token with a note that only these commands will answer, so `big docs:search "…"` works as usual (or skip the file with `BIG_TOKEN=big_pat_xxx big docs:search "…"`). See **[Read the docs with a token](/docs/developers/api-reference#read-the-docs-with-a-token)**. ## Audit history Per-plan audit history retention windows (7/30/90 days) are planned but not yet enforced — today every plan can query its full audit history. ## The weekly usage cap This is the one cap that applies to every workspace, including one that has never touched automations. **Automation steps and form submissions share a single weekly budget:** | Plan | Automation steps + form submissions per week | | ------ | -------------------------------------------- | | teeny | 100 | | tiny | 1,000 | | big | 10,000 | | bigger | 100,000 | The week is the ISO week: the counter resets at **00:00 UTC on Monday**. Your current usage against the cap is on **[Settings → Billing](/docs/guides/account/billing)**. When your workspace crosses 80%, and again at 100%, the workspace owner gets a **[notification](/docs/guides/account/notifications)** in big and the same notice by email. What counts, and what happens when you hit it: * **Automation steps count.** Hitting the cap stops **new** conversations from starting; a conversation already mid-flow is allowed to finish, so some replies still go out afterwards. * **Stored form submissions count** — but a submission is **never refused**. Over the cap, forms keep accepting and storing responses, on every plan, and the visitor sees the same thank-you screen either way. You never lose a lead to your billing state. What changes is when you can *read* it. * **Over the cap, a response is stored locked.** You see that it arrived and when, and it still counts in your response total and conversion rate. The answers, the submitter's identity, and the link or campaign it came from stay hidden until it unlocks. Nothing is deleted and nothing is lost. * **Locked responses unlock at the weekly reset**, oldest first, for as far as the new week's budget stretches. Upgrading unlocks every locked response immediately, whatever the backlog. * **The released backlog is served first, ahead of your automations.** Unlocking draws on the new week's budget before any DM or comment automation does, so your automations only start firing again once the backlog has been cleared. If you are locking more responses each week than your cap covers, the backlog never clears and your automations stay quiet until you upgrade. * **What running out actually costs you is automations.** Because the budget is shared, a form carrying heavy traffic can spend the allowance your DM and comment automations draw on, and those stop starting until the week resets. * **Back-filled Typeform responses don't count.** Past responses you bring in with **[Back-fill past responses](/docs/guides/forms/typeform#back-fill-past-responses)** never count against the cap and are never locked. * **Nothing else counts.** Form views, link clicks, link-in-bio views, and the forms, links, and pages themselves are all free and unlimited on every plan. ## Automations limits Automations are a separate feature from forms and links. Beyond the weekly cap above, they add one limit of their own: * **Active automations** — teeny is capped at 10 active automations; paid plans are unlimited. * **Only switched-on automations count.** A paused automation spends nothing against that cap, however many you keep. That includes the paused **[example automations](/docs/guides#your-example-automation-and-form)** a new workspace starts with — they cost you nothing until you turn one on, and switching both on spends two of your ten. ## Integration limits **[Integrations](/docs/guides/integrations)** connect your other tools to big, with an API key or by signing in to the tool, so your own AI agent can get their context through big's MCP server. | Plan | Integrations per workspace | | ------------ | -------------------------- | | teeny (free) | 2 | | tiny | 5 | | big | 15 | | bigger | 50 | * **The limit counts every integration that isn't disconnected**, including one in **Error** or **Reconnect needed**. A disconnected integration frees its slot straight away, and reconnecting one that needs it doesn't take a second slot. * **It is separate from Instagram and Facebook connections.** Those have their own per-plan count above; the two never share a budget. * **Every provider is available on every plan.** No tool is reserved for a higher tier. * **Downgrading never disconnects anything.** If you move to a plan with a lower limit while you have more integrations than it allows, the ones you have keep working and can still be re-verified, rotated and disconnected; you just can't connect a new one until you're back under the limit. Disconnect the ones you no longer need, or upgrade. See **[Connect an integration](/docs/guides/integrations/connect#if-you-downgrade)**. ## Google Drive folder limits **[Google Drive](/docs/guides/integrations/google-drive)** folders you link are synced into big on every plan, up to these limits, counted across the workspace: | Plan | Linked folders | Synced files | Synced text and files | | ------------ | -------------- | ------------ | --------------------- | | teeny (free) | 1 | 200 | 100 MB | | tiny | 3 | 2,000 | 1 GB | | big | 10 | 10,000 | 5 GB | | bigger | 25 | 50,000 | 20 GB | * **Linked folders don't use an integration slot**, and synced copies don't count toward your Files storage. * **Past a limit, big keeps what it holds current** and adds no new files; the folder shows **Capped**. * **Downgrading deletes nothing.** Linked folders keep syncing; you can't link another, and new files aren't added, until you are back under the limits. ## Scheduled posts **In testing, not available yet.** Scheduling is visible only to big's team for now. These are the limits it will open with. **[Scheduled posts](/docs/guides/scheduling)** are capped per calendar month, counted per account the post goes to, so one post sent to two accounts counts as two: | Plan | Scheduled posts per month | | ------------ | ------------------------- | | teeny (free) | 10 | | tiny | 60 | | big | 300 | | bigger | Unlimited | * **The month is the one the post is scheduled for**, not the month you wrote it. * **Downgrading cancels nothing.** Posts already scheduled still go out; you can't schedule more that month until you're back under the limit. * **Publishing is not switched on yet.** You can plan and schedule posts now; they go out once Instagram publishing is approved. ## Beyond the four plans Need big hosted privately for your company, or want the team to build your setup with you? **big Enterprise** is a private deployment of big with its own database, so every contact, response and message stays in a system you control, with custom integrations packaged in. **big Services** audits how your business wins customers and builds the automations, forms and integrations to run it. Neither is sold through checkout: both are priced per company after a strategy call. See **[Services](/services)** or **[book a call](/book)**. ## Related * **[Billing](/docs/guides/account/billing)** — change plan, see invoices, watch your usage. * **[Your data](/docs/guides/account/your-data)** — export everything, or delete the account. * **[Integrations](/docs/guides/integrations)** — connect your other tools and what each plan allows. --- # Product updates > Source: https://itsjustbig.com/docs/guides/account/product-updates · Last modified: 2026-10-17T00:00:00.000Z Alongside the account notices covered in **[Notifications](/docs/guides/account/notifications)**, big sends one other kind of email: an occasional product-update digest. It is the only marketing email big sends. Some account notices carry their own unsubscribe link too now, but that's a separate mechanism, scoped to one workspace and one notice kind (see the Notifications page for what it does). ## What it is * **A short digest of what shipped**: a handful of entries in plain language, each saying what changed and why you'd care, sometimes with a link to read more. Text only, no images. * **Written by hand**: every entry is written for the send. Nothing is generated from release notes, and nothing about your workspace, your contacts or your usage goes into it. * **On no fixed schedule**: it goes out when there is enough worth telling you about. Nothing mails the list automatically; a person at big writes the issue, reviews it and sends it. ## Why you're getting it You joined big's waitlist before sign-up opened to everyone, and the form said so where you handed over your address: an invite when your seat opened, and the occasional product update in between. The waitlist has closed now that anyone can sign in with Google, and nothing else puts an address on this list. Creating a workspace, being invited to someone else's, or starting a subscription doesn't add you, and neither does contacting support. Every digest repeats it in the footer, next to big's postal address, so you can always tell why an issue arrived. ## How to unsubscribe **Use the link in the email.** Every product-update email carries an **Unsubscribe** link in its footer. Open it to come off the list. You don't need an account, and you won't have to confirm by email. The link is handled by Resend, the email provider big sends through, which is where the list itself lives. That means two things worth knowing: * **The link in the email is still the only way to manage the digest.** **Settings → Notifications** shows a read-only row naming this channel and pointing back to this page, but it doesn't carry a toggle for it: the list itself lives with Resend, not in big's database, so there's nothing in the dashboard to flip. See **[Notifications](/docs/guides/account/notifications)** for what that tab *does* control: the account emails below, not this one. * **If you no longer have a digest to hand**, write to [support@itsjustbig.com](mailto:support@itsjustbig.com) and ask to be taken off the list. ## What unsubscribing does not stop > **Account email is unaffected.** The two paths are separate by construction: this list's unsubscribe link only ever touches this list. Some account notices carry their own, separate unsubscribe link now too (see **[Notifications](/docs/guides/account/notifications)**), but following the one in a digest does nothing to those, and following one in an account email does nothing to this list. * **Notification email**: the usage-cap, failed-renewal and suspension notices that mirror the bell keep arriving, unless you've separately turned one off in **Settings → Notifications**. See **[Notifications](/docs/guides/account/notifications)** for which kinds that is and which one can't be turned off. * **Billing email**: anything about a payment, an invoice or your subscription. See **[Billing](/docs/guides/account/billing)**. If you want every account message to stop as well, that's account deletion rather than an unsubscribe: see **[Your data](/docs/guides/account/your-data)**. ## Related * **[Notifications](/docs/guides/account/notifications)**: the bell, and the account email that mirrors it. * **[Your data](/docs/guides/account/your-data)**: exporting everything your workspace holds, or deleting the account. --- # If your workspace is suspended > Source: https://itsjustbig.com/docs/guides/account/suspended · Last modified: 2026-09-14T00:00:00.000Z A suspension is a pause someone at big applies to a whole workspace, by hand, with a reason recorded at the time. It is never automatic — no usage level, payment state or traffic pattern triggers it on its own — and it is always reversible. **Nothing is deleted.** Your messages, contacts, automations, forms, links and link pages are all still there, you can still sign in and read every one of them, and lifting the suspension starts sending again — with one exception worth knowing up front: a message that was already queued and whose [messaging window](/docs/automations/24h-window) closes during the suspension is dropped rather than delivered late. See [Queued sends](#what-stops). ## How you find out The workspace **owner** gets a [notification](/docs/guides/account/notifications) in the bell and the same message by email. It names the reason, and that notice is where the reason lives — nothing else in the dashboard changes appearance, and other members are not notified separately. ## What stops **New automation runs.** Comments, DMs and story replies still arrive and are still recorded in your Inbox. What doesn't happen is the automation: no new run starts while the workspace is suspended. Nothing is lost on the way in — the trigger simply doesn't fire. **Queued sends.** A message big had already accepted sits in the send queue instead of going out. It is not thrown away, and it does not spend its retries — it waits, and it is re-checked every few minutes, so sending resumes shortly after the suspension is lifted. One thing does keep running while a message waits: **the messaging window**. A queued message whose 24-hour (or 7-day) window closes before the suspension is lifted is dropped rather than delivered late, the same as any other message that outlives its window. See **[The 24-hour window](/docs/automations/24h-window)**. **Everything a token can do.** Personal access tokens and MCP OAuth tokens are refused on the REST API, the CLI, the local MCP server and the remote MCP endpoint, with a **403** carrying `code: workspace_suspended`. Minting a fresh token does not help, and neither does connecting a new MCP client — the OAuth consent screen refuses while the suspension stands, and an already-connected client's token refresh is refused too. The **documentation** reads are the one exception. `big docs:search`, `big docs:read`, their MCP tools and the `/llms.txt` family are not plan-gated and are not suspension-gated either, so they keep answering. ## What keeps working * **Signing in, and the whole dashboard.** Every screen, every number, every record. Reading is never gated. * **Incoming DMs and comments.** They are still received and still land in the Inbox. * **Reacting to a message by hand.** Emoji reactions from the Inbox still go out — a suspension pauses automated sending, and a reaction is not it. (Typing your own reply is a separate matter and is not available to anyone yet, suspended or not: see [Reply by hand](/docs/inbox#reply-by-hand--coming-soon).) * **Forms, short links and link pages.** Still public, still collecting responses, clicks and views. * **Your plan and billing.** Untouched. A suspension is not a downgrade, a cancellation, or a change to what you are charged. ## How to get it lifted Start with the reason — it is in the notification and in the email. If you have fixed what it names, or you think it is a mistake, reply to that email or write to [support@itsjustbig.com](mailto:support@itsjustbig.com). A suspension is lifted by a person, the same way it was applied. ## When it is lifted Automations start matching again, the send queue drains the messages still inside their window, and your existing tokens work again with no need to re-mint them. An MCP client that gave up while it was being refused may need to be reconnected once. ## Related * **[Notifications](/docs/guides/account/notifications)** — the bell, the email, and what else big tells you about. * **[Fix an automation that didn't fire](/docs/automations/why-didnt-fire)** — every other reason a trigger stayed quiet. * **[Troubleshoot an MCP or CLI connection](/docs/developers/mcp/troubleshooting)** — reading a refusal by its status code. --- # Team & roles > Source: https://itsjustbig.com/docs/guides/account/team · Last modified: 2026-10-02T00:00:00.000Z A workspace can have more than one person in it. You invite teammates, and each one gets a **role** that decides what they can see and change. There's no per-plan cap on how many members you can add. Manage everyone under **Settings → Members**. ## Invite a teammate From **Settings → Members**, choose **+ Invite**, enter their email address, and pick a role. big emails them an invite with a **Join** button for your workspace. There's no link to copy and send yourself. * **Invites expire after 7 days.** A pending invite shows whether its email went out. Use **Resend** to send a fresh one (you can resend once a minute). Resending replaces the invite, so the button in any earlier email stops working. Use **Revoke** to cancel it. * **Someone who's already a member can't be invited again.** To change what they can do, change their role in the member list instead. * To protect people's inboxes, there's a daily limit on how many invite emails a workspace can send, and on how many any one address can receive. ### Accepting an invite Your teammate opens the email, chooses **Join**, and signs in with Google using the **same address the invite was sent to**. If they don't have a big account yet, this creates one. If they open the invite while signed in to big with a different Google account, big tells them which address it's for and offers **Switch account**. That signs them out and brings them straight back to the invite with the right account. Joining always takes one more click on the invite page (**Accept and open** your workspace), and they land in your workspace when they do. ## Switch between workspaces Everyone has their own workspace, and you can also be a member of other people's. Accepting an invite doesn't take you out of yours. When you belong to more than one, a workspace switcher appears at the top of the sidebar (on a phone, at the top of the screen). It lists **Your workspaces** and **Shared with you**, with your role in each. Pick one to move there. big remembers your choice on that browser until you switch again or sign out. API tokens and MCP connections are tied to the workspace they were created in, so switching in the dashboard doesn't change what an existing token can reach. ## The four roles Roles are ranked **owner > admin > editor > viewer**. Each higher role can do everything the one below it can, plus more. | Role | Can do | | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Viewer** | Read-only. See automations, conversations, contacts, connections, integrations, and links — but not change anything. | | **Editor** | Everything a viewer can, plus **make changes**: build and toggle automations, send DMs and react in the inbox, tag contacts and set lead status, create or delete short links, and delete forms. | | **Admin** | Everything an editor can, plus manage **connections**, **[integrations](/docs/guides/integrations)** (connect, reconnect, rotate, re-verify, disconnect), **members** (view the team), **API tokens**, and view **billing**. | | **Owner** | Everything. Only the owner can add or remove **admins**, change billing, delete the workspace, or transfer ownership. | These same roles cap what an API token can do — a token can never grant more than its holder's role allows, and a demotion takes effect immediately. ## Rules worth knowing * **Only the owner can promote or demote admins**, or remove an admin. * **You can't remove or change your own role.** * **Integrations belong to the workspace, not to the admin who connected them.** Demoting or removing that admin doesn't disconnect anything. Connecting, reconnecting, rotating and disconnecting happen only in the dashboard; an API token can at most read an integration's status, and no role, token or member of big staff can read a stored credential. See **[Integrations](/docs/guides/integrations#who-can-do-what)**. * **There's exactly one owner**, and ownership can't be transferred yet. If you need to hand a workspace to someone else, contact support. ## Change a role or remove someone From **Settings → Members**, pick a member to change their role or remove them from the workspace. Admins can manage editors and viewers; only the owner can manage admins. --- # Your data > Source: https://itsjustbig.com/docs/guides/account/your-data · Last modified: 2026-10-17T00:00:00.000Z Both actions live under **Settings → Account**, and both are **owner-only**. Admins and editors see a notice explaining that only the workspace owner can export or delete. ## Export everything **Export my data** downloads one JSON file containing what the workspace holds: * the workspace record (name, slug, plan, subscription status, created date); * connected Instagram accounts — **without any token material**; * connected **[integrations](/docs/guides/integrations)** — never the key itself, which nobody can read back once saved; * contacts, tags, contact–tag assignments, and contact identities; * messages and their attachments; * automations; * forms and form responses; * short links; * media assets. Each section carries a `truncated` flag. It's `false` in every normal case; a workspace large enough to pass the per-table export ceiling gets an honest `true` rather than a silently short file. This is the GDPR Article 20 (portability) route. It's a dashboard download — it is deliberately **not** reachable with a personal access token, because the file contains every contact's messages and form answers, and a leaked token must not be able to pull it. ## Erase one contact When one of your fans asks you to delete what you hold about them (a GDPR Article 17 request, where you are the controller), you can erase that one contact without touching the rest of the workspace. This takes the **admin** role and is available through the API, the CLI and the local MCP server: * `DELETE /api/contacts/:id` * `big contact:delete ` * `big_contact_delete` (local MCP, requires `confirm: true`) Erasing a contact deletes it together with everything that names that person: their DM history, identities (email, Instagram handle claims), tags and lead state, their form responses, any DM still queued to them, and their comments on your posts. A `contact.erased` entry goes in the workspace audit log with counts only, never the person's details. It cannot be undone. One thing is kept on purpose: if the person is on your **automation whitelist**, that entry stays, because it is what stops your automations messaging them again. The remote MCP server (`/api/mcp`) has no erase tool, as with every permanent delete. ## What big records about your API tokens Separately from the export above, big keeps a small usage record for every **[personal access token](/docs/developers/authentication)** and remote-MCP grant, so we can see which tokens are active and which surfaces are worth investing in. Two things are stored: * **Last used.** A single timestamp on the token itself, shown beside it in **Settings → API tokens**. It is overwritten on every call, so it tells you a token is alive, not what it has done. * **A daily call tally.** One row per token per day per surface per client, holding a count. "This token made 214 calls to the contacts endpoint on 14 August, from the CLI" — nothing finer. It is a running total, not a log of individual requests, so there is no way to reconstruct one call from it. What that tally does **not** hold: the token value or its hash, IP addresses, request bodies, query strings, the names of the contacts or forms you touched, or anything else about the people in your workspace. The `client` field is the **[`X-Big-Client`](/docs/developers/authentication#identifying-your-client)** hint the caller sent — `cli`, `mcp-local`, `mcp-remote`, `sdk`, or `unknown` when it sent nothing. It is kept for **200 days** and then deleted automatically. It is also erased sooner in two ways: **deleting a token** removes its tallies with it (revoking one does not — a revoked token's history stays readable to us), and **deleting the account** below erases all of it along with everything else. It is not included in the export file above, which covers workspace content rather than operational counters. Ask support if you want your workspace's tallies and we will send them. ## Integration keys you give big When a workspace admin connects an **[integration](/docs/guides/integrations)**, big stores a credential so it can call that tool on the workspace's behalf: an **API key** the admin pastes (Calendly, Discord), or a **sign-in token** the tool issues when the admin approves big's read-only access, for an integration your workspace has been set up for. **[Integration security](/docs/guides/integrations/security)** has the full detail; the parts that concern your data are: * **What is stored.** The key or the sign-in tokens, encrypted; which provider it's for; the label you gave it; the account it belongs to on the tool's side, as the tool reported it when big checked it (its account id and its account name or label); for a pasted key, its last 4 characters and a short fingerprint so you can tell keys apart; and when it was connected, last checked and last used. For most tools nothing else about the tool's account is kept: big reads from the tool only when your own AI agent asks, and doesn't copy its data into big. **An integration your workspace has been set up for to feed client records is the exception**: a meeting tool imports call transcripts, attendee names and emails, and AI summaries; a file store keeps the text of the documents in the folders shared with big; a calendar imports the times of events your clients attend and which clients are on them. Raw copies of transcript files and of file text are kept in private storage. Disconnecting the integration deletes all of it, and a file store's documents are deleted once they leave a folder shared with big. * **Nobody can read a key or token back.** Not you, not your admins, not big staff. No screen, API, CLI command or MCP tool returns one. * **Google Cloud is a sub-processor for pasted keys and sign-in refresh tokens only.** Each pasted key, and each refresh token a tool issues when you approve big, is encrypted with its own key, and that key is itself encrypted ("wrapped") by a master key held in Google Cloud KMS hardware. To wrap and unwrap it, Google Cloud KMS receives that key itself, along with internal ids (the workspace's and the integration's, and the provider's or the connection version's) that bind it to this one connection. It **never receives your API key or refresh token, nor the encrypted copy of either**, nor any of your workspace content. So Google Cloud alone can't decrypt anything, and neither can big's database alone. * **Short-lived access tokens don't involve Google Cloud.** They are encrypted with big's own token key, which lives only in big's production environment. Sign-in tokens of both kinds are kept in a separate table that big's application code can't read directly. * **Disconnecting deletes the credential from big's live database immediately.** A small record (provider, label, account, dates, a key's fingerprint) stays for your workspace's audit history and is deleted with the workspace. * **Backups.** big's database backups let us restore the database to a point in the past for a limited window, so a deleted key or token still exists, encrypted, inside those backups until that window (`NEON_PITR_DAYS` days) has passed. Only big's production service holds what it takes to decrypt it, and after the window it is gone from backups too. * **Deleting big's copy doesn't invalidate it at the tool.** An API key is created and revoked in the tool that issued it, so after you disconnect or rotate, delete the old key in that tool too. Disconnecting a tool you signed in to asks the tool to revoke big's access where it can. ## Delete the account The **Danger zone** deletes the whole workspace. You have to type the workspace name exactly to confirm, and that's re-checked on the server, so the confirmation can't be skipped. What happens, in order: 1. **Your subscription is cancelled first.** If cancelling fails, nothing is deleted — you'll be told to retry or contact support. Deleting the data while billing kept running would be the worst outcome, so it's the first step and it's allowed to abort the rest. 2. **Uploaded files are purged** from storage. If the purge is cut short (a very large workspace, or the storage provider fails), big records the leftover files and keeps retrying the purge in the background until they are gone. The deletion itself still goes ahead. 3. **The workspace is deleted**, and everything scoped to it goes with it: connections, integrations and their stored keys, contacts, messages, automations, forms, links, tokens, and memberships. Your public link pages go offline straight away, and their handles become free to claim. big can't revoke integration keys at the tool that issued them, so delete those keys there too. 4. **Your login is deleted only if this was your last workspace.** If you belong to other workspaces, you keep your account and your access to them. Other members' logins are never touched — only their membership of this workspace disappears. Your Stripe customer record and past invoices are kept. Invoices are retained for tax and accounting obligations; they're no longer linked to a live workspace. This is the GDPR Article 17 (erasure) route, it is irreversible, and — like the export — it is owner-only and unreachable with a personal access token. **One thing it does not cover: the product-update mailing list.** If you're on it — you joined it through the waitlist, before sign-up opened to everyone — your address sits with Resend, the email provider big sends through, rather than in the workspace. So it is not in the export above, and deleting the account does not take it off the list. Use the unsubscribe link in any product-update email, or write to [support@itsjustbig.com](mailto:support@itsjustbig.com) to have the address removed. See **[Product updates](/docs/guides/account/product-updates)**. ## Related * **[Billing](/docs/guides/account/billing)** — cancel a subscription without deleting anything. * **[Team & roles](/docs/guides/account/team)** — who can do what. * **[Integration security](/docs/guides/integrations/security)** — how integration keys are stored and deleted. * **[Product updates](/docs/guides/account/product-updates)** — the mailing list, and how to leave it. --- # Field types > Source: https://itsjustbig.com/docs/guides/forms/field-types · Last modified: 2026-10-17T00:00:00.000Z Forms support 13 field types. Here's what each one is for, and exactly what big checks before accepting a submission. You pick the type in a page's editor, on the **Type** control beside the question's label. Each question in that panel is numbered in the order it's asked, and that number is how the rest of the builder refers to it — the branching rules and the per-field visibility conditions both name a question by its number and label. The type is not only about validation: it decides **what you can branch on**. Single choice, Dropdown and the Agreement scale give a fixed list of answers to match against, Number and Rating compare with *at least* / *at most*, Date matches an exact day, the text types (Phone and Website included) can be tested for *contains*, and Multiple choice can't be branched on at all. [Conditional logic](/docs/guides/forms/logic) has the full comparison table. ## Text and numbers * **Short text** — a single-line answer, up to 5000 characters. * **Long text** — a multi-line answer, also up to 5000 characters. * **Number** — must be a finite number (no `Infinity`, no `NaN`). ## Email Validated against a standard email format. big checks the shape of the address, not whether it's deliverable. ## Instagram handle Validated for **format only** — lowercase letters, numbers, periods, and underscores, 1–30 characters (`[a-z0-9._]{1,30}`). big does **not** verify that the handle belongs to a real, existing Instagram account — there's no public API for that lookup. Treat a submitted handle as "shaped like a handle," not "confirmed to exist." ## Phone A one-line box for a phone number. big accepts the number with or without spaces, dots, dashes and brackets, and with an optional leading `+` (or `00`, which big stores as `+`). What's left must be **7 to 15 digits**, and big stores it in that compact form, so `+1 (555) 010-9999` is saved as `+15550109999`. big checks the shape only; it doesn't call or text the number, or check that it's in service. A phone field can be the form's [identity field](#identity-field), with one difference from email. See below. ## Website A one-line box for a web address. It must be an `http://` or `https://` address; a bare domain like `example.com` is accepted and stored as `https://example.com/`. Any other kind of address (`mailto:`, `ftp:`, and so on) is refused. big doesn't visit the address or check that the site exists. ## Date A date picker. The answer is stored as a calendar day in `YYYY-MM-DD` form, with no time and no time zone. An impossible date such as `2026-02-30` is refused rather than rolled over to the next month. If a date arrives with a time attached (from an import or the API), big keeps the date part only. ## Choice fields * **Single choice** — pick one option. * **Multiple choice** — pick one or more options. * **Dropdown** — pick one option from a dropdown list; big also validates that the submitted value is one of the configured options. All three share the same option limits: **1–50 options**, each up to **200 characters**. ### Other answers Single choice and Multiple choice can also take an **Other** answer: tick **Allow an Other answer** on the question. Visitors then see an **Other** choice with a text box, and whatever they type, up to 500 characters, is saved as their answer. On Multiple choice it's saved next to the options they ticked. Dropdown has no Other answer. An Other answer that spells one of the options, ignoring capitals and spaces, is saved as that option. Any other Other answer matches no option, so a fork such as *equals Strength* doesn't fire on it, and *doesn't equal Strength* does. ## Rating An integer rating scale. Both ends are configurable per field: the **minimum** can be from 0 to 9 (default 1) and the **maximum** up to 10, with the minimum always lower than the maximum. A 0 to 10 scale is how you ask a "how likely are you to recommend us" (NPS) question. You can also flip the scale so the highest value renders first. A rating can also carry up to three optional **scale labels**, shown under the numbers: **Low end**, **Middle** and **High end** (for example *Not likely*, *Neutral*, *Very likely*), each up to 200 characters. Leave them blank and the scale shows numbers only. When you flip the scale, the low and high labels stay with their numbers, so they swap sides with them. ## Agreement scale A fixed **5-point agree/disagree scale** (for example, *Strongly disagree → Strongly agree*). Unlike Rating, the points are fixed at five and stored by their label. You can flip the rendered order (strongly-agree first) without changing what's stored. (This type is called *likert* in the API and the CLI's schema output; the dashboard names it Agreement scale.) ## Identity field You can flag exactly **one** field on a form as the **identity** field — a **short text**, **email**, **Instagram handle** or **phone** field is eligible. Whatever a respondent enters there is copied to that submission's identity value, which is what big uses to recognize or de-duplicate who responded. The identity value is the only form answer big matches against anything else (it's also what connects a response back to the short link that brought the person in). No other field is looked up or cross-referenced. ### A phone identity is stored, not matched A phone number in the identity field is saved as the response's identity. But big **creates no client and no contact from it, and doesn't link the response to an existing client**: [Create clients from responses](/docs/guides/forms/typeform#create-clients-from-responses) matches by email only. The new-response notification doesn't name a phone respondent either. If you want responses to become clients, make an **Email** field the identity instead. --- # Forms > Source: https://itsjustbig.com/docs/guides/forms · Last modified: 2026-10-17T00:00:00.000Z A form is a public page at `/f/:slug` that collects structured responses from anyone with the link. No Instagram connection, no code. ## What a form is Each form lives at its own `itsjustbig.com/f/` address. Visitors fill it out and submit — you see the responses in your dashboard. That's the whole loop. ## Create a form 1. Open **Forms** in big and click **New form**. 2. Give it a **title**. 3. Add your fields — see **[Field types](/docs/guides/forms/field-types)** for what's available. 4. Set **status** to `active` when you're ready to accept submissions. Already have a form in Typeform? You can **import it** instead of rebuilding it: open **Forms → Import**, connect your Typeform account, and pick a form to bring over. You can also keep a form in Typeform and have its new responses sent to big. See [Typeform](/docs/guides/forms/typeform) for both. ## Form settings * **Title** — shown at the top of the public form. * **Status** — `draft`, `active`, or `closed`. Only `active` forms accept submissions; `draft` and `closed` forms still exist and can be viewed in your dashboard, but visitors can't submit to them. * **Slug** — auto-generated from the title when you create the form. There's no way to change it afterward, so don't rely on the slug spelling out something you might want to edit later. ## Delete a form Deleting a form takes **everything attached to it**: every saved version of its schema, every response it has collected, and its whole view and funnel history. Its `/f/` address stops resolving. **There is no undo and no trash** — rebuilding the form gets you the questions back, never the answers. You need the **editor** role or higher, the same floor as deleting an automation. The control is on the form row's overflow menu and in the builder's header, and the confirmation names how many responses go with it, so you see the cost before you agree to it. **If you only want to stop accepting submissions, set the status to `closed` instead.** That keeps the form, its responses and its public page; it just stops taking new answers. Delete is for a form you want gone. Deleting is on the developer surface too, mirroring automation delete exactly: * **CLI** — `big form:delete `, scope `forms:write`. Like `big rule:delete`, it takes no confirmation flag — it deletes as soon as you press enter. See **[the command reference](/docs/developers/cli/command-reference#forms)**. * **Local MCP** (`big mcp`) — the `big_form_delete` tool, scope `forms:write`, editor+. Like `big_rule_delete` it is **[confirm-gated](/docs/developers/mcp#the-confirm-gate)**: the call refuses without `confirm: true`, so a model can't delete a form on the strength of something it read in a DM. * **REST** — `DELETE /api/forms/:id`, scope `forms:write`, editor+. See **[the API reference](/docs/developers/api-reference#forms)**. * **Remote MCP** — not offered, like every other delete. The hosted server carries no destructive verbs. An **[example form](/docs/guides#your-example-automation-and-form)** left over from onboarding deletes exactly like any other, and nothing puts it back. ## Pages and logic A form isn't limited to a single screen. You can split it into **multiple pages** (up to 20) — use **+ Add page** at the top of the canvas — and add **conditional logic**: * **Show a field only when it's relevant** — a field can be set to appear based on an earlier answer. * **Branch between pages** — at the end of a page, send the respondent to a different page (or straight to submit) depending on what they answered. This lets one form ask follow-up questions that only apply to some people. You build it visually in the form editor — there's nothing to write. **[Conditional logic](/docs/guides/forms/logic)** covers the rules in detail. Each page can carry an optional **title** and **description**, set in the page editor; the description shows under the title as plain text (up to 1000 characters). On a one-page form it shows under the form's title. ## The confirmation screen You can customize what a respondent sees **after they submit**: * A custom **heading** and **message** (your own thank-you text). * An optional **button**, with your own label, that sends them somewhere next. Leave these blank and big shows a standard thank-you. ### Where the button sends people In the form editor, open the **submit** step at the end of the flow and pick one of three destinations: * **Nothing** — no button at all, just your thank-you text. * **A link** — any `http(s)` address you paste. Your shop, your newsletter, a booking page: anything outside big. * **One of my link pages** — pick one of your workspace's **[link pages](/docs/guides/trees)** from a list, instead of pasting its address. Whichever you pick, you give the button its own label — "See everything else", "Book a call". The button opens in the **same tab**: this is the end of your funnel, so the visitor moves on rather than leaving a dead thank-you screen stacked behind them. The setup this exists for: one link in your Instagram bio points at the form, so the bio link captures a lead, and the thank-you offers your link page — everything else you sell — to the person who wanted more than one thing. ### Picking a link page instead of pasting its URL Two things change when you pick a page rather than typing its `itsjustbig.com/t/` address into **A link**: * **Renaming the handle doesn't break the button.** big stores *which page* you picked, not its address, and looks the current address up each time the thank-you renders. A pasted URL would break the moment you rename: the old handle stops working immediately, with no redirect, and can be claimed by someone else — see **[Renaming a handle](/docs/guides/trees/publish#renaming-a-handle)**. * **Only a published page shows a button.** You can pick a draft — the picker says so when you do — but the button stays hidden on the live thank-you until you publish that page. The same goes for a page you later unpublish or delete: the button disappears rather than dead-ending, and visitors are never told why something is missing. ## What's not there yet To set expectations up front, a form today does **not** support: * A description for the form as a whole (each page has its own optional title and description instead) * An automatic redirect after submit — the confirmation button is always something the visitor taps, including when it points at one of your link pages; the page never forwards on its own * A count of taps on that button. A link page records the visit as a page view, but nothing splits those views by where they came from (see **[Link page stats](/docs/guides/trees/stats)**), and a tap on an external link isn't recorded at all * Logo, color, or other branding configuration If you need any of these, they're not available yet — don't build a workflow that depends on them. ## Fields Forms support 13 field types, each with its own validation. See **[Field types](/docs/guides/forms/field-types)** for the full list. ## Share it Once a form is `active`, share the public link or turn it into a trackable short link. See **[Share your form](/docs/guides/forms/sharing)**. ## Limits * 1–100 fields per form, across 1–20 pages. * Each field needs a unique field ID. * Submitted answers are capped at 16KB total per submission. * There's no plan-based cap on the number of forms or fields — every plan gets the same limits above. * **Submissions count against your plan's weekly cap**, which they share with automation steps. Views don't count; only a stored submission does. * **A submission is never refused for being over the cap.** Going over the cap never costs you a response: every submission is accepted and stored, on every plan, at any usage level. The visitor sees the same thank-you screen either way, and only ever sees it once the response is saved. See **[Anti-spam](/docs/guides/forms/sharing#anti-spam)** for the rate limits, which are separate from the cap. * **Over the cap, a response is stored *locked*.** You still see that it arrived, when it arrived, and it still counts in your totals and conversion rate. You don't see the answers, who submitted it, or which link or campaign it came from, until it unlocks. * **A coaching practice's Client check-in form is different.** It stores no response, never counts against the cap, and drops a submission that has no valid link code from a client's update link. See **[The client check-in form](/docs/client-records/check-in-form)**. * **Locked responses unlock at the weekly reset**, oldest first, as far as the new week's budget stretches. Upgrading unlocks all of them immediately. * **The unlocked backlog is served before your automations.** Releasing locked responses draws on the new week's budget first, so DM and comment automations only start firing again once the backlog has been cleared. A backlog bigger than your weekly cap drains over several weeks, and your automations stay quiet the whole time. See **[Plans](/docs/guides/account/plans#the-weekly-usage-cap)**. --- # Conditional logic > Source: https://itsjustbig.com/docs/guides/forms/logic · Last modified: 2026-10-17T00:00:00.000Z Logic makes one form work for different people: skip the questions that don't apply, and route each respondent to the pages that do. There are two kinds, and both are built visually in the form editor. ## Show a field conditionally Any field can carry a **visibility condition**: show this field only when an *earlier* field's answer matches. A field with no condition always shows. Open a question in the page editor and tick **Only show this question when…** to add one. The condition must point at a field on a **previous page** — a field can't depend on an answer from its own page or a later one, so the control doesn't appear at all on page 1. A hidden field is simply skipped; nothing is recorded for it. ## Adding a page Three places make one, and they put it in different spots: * **`+ Add page`**, at the top of the canvas, is the one to reach for first. It adds a page at the end, just before Submit, and opens it. If the old last page was set to send **everyone else** straight to Submit, that is switched back to "next page" so the new page follows it. If the old last page routes somewhere else (back to an earlier page, say), nothing leads to the new page yet: the canvas and the page editor say **not reached yet** until a fork rule or an earlier page's **everyone else** points at it. * **`+ Add page`**, in the footer of the page editor, adds a page right after the page you're editing and opens it. Nothing is routed anywhere — a page with no fork rules just flows into the one after it, so the new page is already the next step. * **`+`**, on the connector between two cards on the canvas, inserts a page *at that exact point* in the flow, and its menu also offers **Fork from this page**. A form holds up to **20 pages**; at 20 the add buttons disable and say why. ## Branch between pages Each page can end with **fork rules**: "if the answer to X is …, then go to page Y." They live under **After this page** in the page editor, numbered *rule 1*, *rule 2*, and so on. When the respondent finishes the page, big checks the rules in that order and the first match decides where they go next. Things to know about targets: * A rule can point at **any other page** — later or earlier — or straight to **submit** to end the form early. What big rejects is a loop: a route that could send someone round in circles won't save. * The destination list also offers **+ A new page**. Picking it creates the page and points the rule at it in one step, which is how you build a branch on page 1 of a new form — there is no other page to choose yet. * **Everyone else** is where a respondent goes when no rule matches. Leave it alone and that's the next page in order, or submit if this is the last page. * A rule that's missing its question, its answer or its destination routes nobody. The editor says so under the rule rather than saving a branch that can never match. A page can hold up to **10 fork rules**. ## What conditions can test The comparisons available depend on the field type you're testing: | Field type | Available comparisons | | ---------------------------------------- | ---------------------------------------- | | Short text, email | equals, doesn't equal, contains | | Long text | contains | | Instagram handle | equals, doesn't equal | | Phone, website | contains | | Date | equals, doesn't equal (an exact day) | | Number, rating | equals, doesn't equal, at least, at most | | Single choice, dropdown, agreement scale | equals, doesn't equal | | Multiple choice | none — can't be tested (yet) | So "rating at most 3 → go to the feedback page, everyone else → submit" works; branching on a multiple-choice answer doesn't. A question big can't test never appears in a rule's question picker, so if one is missing from the list, check its type first. ## A worked example Say you're screening collaborators: 1. Page 1 asks "Are you a brand or a creator?" (single choice). 2. A fork rule on page 1: *brand* → page 2 (budget questions); **everyone else** → page 3 (portfolio questions). 3. On page 2, a "Budget" number field with a visibility condition on an earlier answer, shown only when relevant. 4. Page 2's exit jumps straight to **submit**, skipping the creator pages. One form, two experiences, and nobody sees a question that wasn't meant for them. --- # View form responses > Source: https://itsjustbig.com/docs/guides/forms/responses · Last modified: 2026-10-01T00:00:00.000Z ## Responses table Open **Forms → your form → Responses** to see everyone who submitted, newest first. The table shows up to the most recent **500** responses. There's no CSV or other export yet — responses are viewed in the app. ## Getting told when one arrives Each new response notifies the workspace owner, once per submission, in the bell and by email. The notice names the form and, when the form collects an email or Instagram handle, who sent it; the answers themselves stay here. Opening it brings you to this tab. A response stored locked because the workspace is past its weekly cap doesn't notify. You can turn the email off in **[Settings → Notifications](/settings?tab=notifications)**, and the bell keeps the notice either way. See **[Notifications](/docs/guides/account/notifications)**. ## Views vs. submissions big also tracks page views on your public form. Views are counted in a privacy-friendly way: no raw IP address is stored, and bot traffic is excluded. Next to the responses table you'll see a views-to-submissions conversion rate, so you can tell how many visitors actually filled out the form versus just looked at it. That rate answers "how many of the people who saw it finished?" To find out where the people who *started* gave up, see [Form stats](/docs/guides/forms/stats) — it breaks the funnel into viewed, started, and completed, and reports drop-off page by page. Each response also records which [version](/docs/guides/forms/versions) of the form it was answered on, so an old answer is always read against the questions that were actually asked at the time. A field that didn't exist in someone's version shows as *not asked*, which is deliberately distinct from a question they were asked and left blank. ## Click-to-response linking and your privacy disclosures When an automation DMs one of your short links and the recipient clicks through to one of your forms, big sets a first-party cookie (`bc_session`) in that visitor's browser for up to 7 days. The cookie is a random identifier — it contains no personal data — and exists only so a later submission on your form can be shown to you in the context of the conversation that produced it. It is never used for advertising or analytics and is never shared with third parties. You are the controller for your audience's data, so your own privacy disclosures should mention this. Paste-ready boilerplate you can adapt: > When you open a link I share on Instagram, a first-party cookie may be set in your browser for up to 7 days so that, if you then submit one of my forms, I can see your response in the context of our conversation. The cookie contains no personal information, is not used for advertising, and is not shared with anyone else. Every public big form also carries a short notice near the submit button telling visitors their response may be linked to their Instagram conversation with you. --- # Share your form > Source: https://itsjustbig.com/docs/guides/forms/sharing · Last modified: 2026-10-10T00:00:00.000Z Once a form is `active`, there are two ways to send people to it. Getting it there is one click in the dashboard. From the **[CLI](/docs/developers/cli/command-reference#forms)**, the API, or an AI agent you have connected, you can ask for it instead — but a form only goes live once a person opens the form's **Approve a form publish** screen (`/forms//approve`), reads the questions it will publish, and enters the approval code the request printed there. A code typed on any other screen approves nothing. See **[A version isn't the same thing as publishing](/docs/guides/forms/versions#a-version-isnt-the-same-thing-as-publishing)**. ## The direct link Every form has a public address at `itsjustbig.com/f/`. A simple single-page form works even without JavaScript — visitors can fill it out and submit on a slow connection or a stripped-down browser. Forms that use multiple pages or conditional logic step through in the browser, so those need JavaScript. The **Client check-in** form a coaching practice gets is the exception: its public link works only with the code in a client's update link, so sharing the bare address or a short link to it doesn't let anyone send a check-in. See **[The client check-in form](/docs/client-records/check-in-form)**. ## Shorten it From the form, click **Shorten it →** to mint a short link in one click. The short link is tied back to the form (`form_id`), so its clicks and this form's submissions can be looked at together. See **[Short Links](/docs/guides/links)** for what a short link is and how its stats work. ## Anti-spam Submissions are rate-limited, and forms carry hidden honeypot fields, a minimum fill time and basic bot filtering to keep automated noise out. This protects your form from casual spam — it isn't a claim of airtight security, and there is no captcha. The rate limits work at three levels: per visitor's network address, per form, and across your whole workspace. The form and workspace ceilings are high enough that ordinary traffic, even a busy launch, never reaches them; they exist so a single script can't flood a form. A visitor who does hit a limit stays on the form with their answers and a message asking them to try again in a minute. **The thank-you screen means the response was saved.** If a submission can't be saved (a temporary error on our side, a limit, or an answer that didn't pass the form's checks), the visitor stays on the form with their answers kept and a message saying what to do. With JavaScript turned off in their browser, they're returned to the form with the same message but have to fill it in again. Because a stored submission counts against your **[weekly cap](/docs/guides/account/plans#the-weekly-usage-cap)**, spam that gets past those filters spends the same budget your automations draw on. A real submission is still never refused — every one is stored, on every plan. But once the cap is spent, the responses that arrive after it are stored **locked**: you see that they came in, not what they say, until they unlock at the weekly reset. Junk traffic can therefore lock up the genuine leads behind it and, because the released backlog is served before your automations, keep those automations quiet into the following week too. If a public form starts drawing junk traffic, check your usage on **[Settings → Billing](/docs/guides/account/billing)**. ## Branding On the free (**teeny**) plan, public forms show a small "Powered by big." footer. Paid plans don't show it. There's no embed or iframe support for forms, and no QR code generation — both are unavailable today, share the direct link or the short link instead. --- # Form stats > Source: https://itsjustbig.com/docs/guides/forms/stats · Last modified: 2026-07-25T00:00:00.000Z Every form records what happens to the people who see it — not just who finished. The **Stats** button on the Forms page opens the workspace funnel; each form links through to its own breakdown. ## The funnel Three stages, in order: * **Viewed** — the form page loaded. * **Started** — the visitor put their cursor in a field. Reading the form and leaving without touching anything counts as a view, not a start. * **Completed** — the form was submitted. The gap between Viewed and Started is a **first-impression** problem: people arrived and didn't begin. The gap between Started and Completed is a **form** problem: people began and gave up. ## Two rates, because they answer different questions * **Completion rate** — completions as a share of everyone who *saw* the form. * **Finish rate** — completions as a share of everyone who *started* it. A form can have a great finish rate and a poor completion rate. That means the form itself is fine and the problem is upstream — the page it's embedded on, the link you shared, or who you're sending. Collapsing both into a single "conversion rate" hides exactly that distinction, so big shows you both. **Dropped out** counts visitors who started, left, and never came back. ## Where people drop off For forms with more than one page, each page reports its own outcome: * **Reached** — visitors who were on this page. * **Moved on** — reached it and continued (or submitted from it). * **Dropped here** — reached it and left. Each page is measured against its **own** reach, not against the first page. That matters when your form branches: someone who skips a page because of [logic](/docs/guides/forms/logic) hasn't dropped off — they were never asked. Counting them as a drop-off would make every branched form look broken. Pages are tracked by identity, not position, so reordering your pages or inserting a new one doesn't scramble your history. A page is highlighted when it's losing a meaningful share of the people who reach it. Pages with only a handful of visits aren't flagged — a page that lost "100% of visitors" when two people saw it isn't a finding, it's noise. Pages you've since deleted still appear, marked as removed, so the drop-off they caused isn't quietly erased from your history. ### Why the numbers may not add up **Reached** is usually a little larger than **moved on** plus **dropped here**. That's deliberate. When someone closes a tab, their browser sends a final best-effort signal, and sometimes it doesn't arrive — commonly when a phone goes to sleep or an app is force-closed. Rather than guess, big counts that visitor as having reached the page and leaves them out of both outcomes. The alternative would be to treat every missing signal as a drop-off, which would quietly inflate the one number you most need to trust. ## Time on the form **Average time to complete** is measured across people who actually finished. Abandoned sessions aren't averaged in — they'd drag the number toward "how long people lasted before quitting," which is a different question. ## What's excluded Bots and link-preview fetchers are excluded from every number here, exactly as they are in [link stats](/docs/guides/links/stats). Play-testing your own form in the builder records nothing, so you can preview freely without touching your numbers. ## Privacy big never stores your visitors' raw IP addresses. Everything on this page is counted from your own workspace's records — no third-party analytics service sits between you and these numbers. ## How fresh is this Stats are computed live when you load the page. There's no overnight batch and no precomputed rollup — every view reflects the current data. --- # Typeform > Source: https://itsjustbig.com/docs/guides/forms/typeform · Last modified: 2026-10-19T00:00:00.000Z big connects to Typeform in two ways. You can **import** a form, which copies its questions into a big form once. And you can **receive responses**, which sends every new submission on a Typeform form to big as it happens, so you can keep collecting applications in Typeform. Both use the same Typeform connection. ## Connect Typeform Open **Forms → Import** and choose **Connect Typeform**. Typeform asks you to approve big's access, then sends you back. Connecting needs the **admin** role. big asks Typeform for permission to: * read your account and your forms, to list and import them * read responses and manage webhooks, so big can receive new responses for the forms you choose A Typeform account can be connected to one big workspace at a time. If it's already connected in another workspace, disconnect it there first. ## Approve once more if you connected before Connections made before response intake existed only allowed importing. They keep importing exactly as before, but they can't receive responses until Typeform approves the new permissions. If yours is one of them, **Forms → Import** and **Connect** both show a **Reconnect Typeform** prompt. An admin chooses it, approves in Typeform, and is done. Nothing you already imported changes. ## Import a form Once connected, **Forms → Import** lists every form on your Typeform account, one card per form. Choose **Import →** on one to copy its questions into a new draft form in big. Importing needs the **editor** role. An import is a copy, not a sync. Re-importing the same form later updates the big form and saves a new [version](/docs/guides/forms/versions). Re-importing is refused if you've since changed the form's shape in big: added [branching](/docs/guides/forms/logic) or a custom confirmation screen, or added, removed or renamed a page, or added or changed a page's description. Typeform's copy would replace that work, so big says so and leaves the form alone. Edit the form in big instead. Changing questions in big doesn't block a re-import; the re-import replaces them with Typeform's. ## What carries over An import copies the questions, their order, and whether each one is required. It doesn't copy Typeform's logic jumps, hidden fields, endings, images, or theme. | In Typeform | In big | | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Short text, Long text, Email, Number | The same type | | Phone number | [Phone](/docs/guides/forms/field-types#phone) | | Website | [Website](/docs/guides/forms/field-types#website) | | Date | [Date](/docs/guides/forms/field-types#date) | | Multiple choice | Single choice, or Multiple choice if it allows several answers, with an [Other answer](/docs/guides/forms/field-types#other-answers) if it has an *Other* option | | Dropdown | Dropdown | | Yes/No | Single choice with *Yes* and *No* | | Legal | Single choice with *I accept* and *I don't accept* | | Rating | Rating, up to 10 | | Opinion scale | Rating with the same range (starting at 0 or 1) and its end labels | | Net Promoter Score® | Rating from 0 to 10 | | Picture choice | Single or Multiple choice with the labels only; the pictures are dropped | | Contact info | One question per part (name, email, phone and so on) | | Question group | A page of its own, titled with the group's title and description | | Statement | The title and description of the page that starts with the questions after it | **Pages.** Each question group becomes its own page, and a statement starts a new page. Questions that sit between groups go on a page of their own. A group inside a group is merged into its parent's page, and a form that would need more than 20 pages keeps 20, with the extra questions on the last one. A statement with no question after it is dropped. **Identity.** The first email question becomes the form's [identity field](/docs/guides/forms/field-types#identity-field). If there's no email question, the first phone question does, and big [doesn't create clients from a phone identity](/docs/guides/forms/field-types#a-phone-identity-is-stored-not-matched). **What's skipped.** Payment, Calendly, Ranking, Matrix, Multi-format and File upload questions have no big equivalent and aren't imported, nor is any question type big doesn't recognize. A form holds up to 100 questions, so anything past the 100th is dropped too. After an import, the form says how many questions changed shape or couldn't be brought over. ## Receive responses from a form On **Forms → Import**, an admin sees four numbered steps under each form's title, in the order you set them up: 1. **Receive responses**: a switch that brings the form's new Typeform submissions into big as responses. 2. **[Back-fill past responses](#back-fill-past-responses)**: copies in what the form collected before it was receiving. 3. **[Who fills it in](#forms-your-existing-clients-fill-in)**: **Anyone**, or **Existing clients** for a form only your clients get. 4. **[What goes to Notion](#choose-which-answers-reach-notion)**: the answers the form's Notion pages may show. Steps 2 to 4 are shown on every form, so you can see what each one does before you need it. On a form that isn't receiving they are locked and say **Turn on Receive responses first.** Steps 3 and 4 also need the form imported into big, and say **Import this form first.** until it is. A step whose settings couldn't be read says **Couldn't load this step. Refresh to try again.** big loads these settings for your 200 newest imported forms, so on an older form steps 3 and 4 say **This page loads settings for your 200 newest imported forms, and this form isn't one of them.** Refreshing doesn't change that. The first time you open **Forms → Import**, Dot walks you through the page, including each step an admin sees. Press **Show me around** in the corner to take the tour again. Turn on **Receive responses** for every form whose submissions you want in big, such as your client application. You don't need to import the form first: turning it on imports the form as a draft if big doesn't have it yet. The switch flips straight away and says **Connecting to Typeform…** until Typeform has accepted the change. If Typeform refuses, the switch turns back off and says why. Choosing forms for intake, and the other three steps, need the **admin** role, and they can only be done in the dashboard. Editors and viewers don't see the steps. Each form shows them one status line instead: **Receiving responses**, with when the last response arrived, or **Not receiving responses**. API tokens, the CLI and connected agents can't turn it on or off. What happens when you turn it on: * big creates a private signing secret for that form and registers a webhook on the form in your Typeform account. You'll see it under the form's **Connect → Webhooks** in Typeform. * Each new submission is sent to big, stored, then checked against that secret before it is used. Anything that isn't signed with the secret is discarded and never becomes a response. * If Typeform delivers the same submission twice, big keeps one copy. Usually within moments, and at most about five minutes later, each received response becomes a response on the imported big form, so you'll find it on that form's **Responses** tab next to responses from big's own form page. Receiving responses works alongside an import: if the imported big form is deleted later, big holds the form's responses for up to a week and adds them once you import it again. Each form that is receiving responses shows, under the switch, when its last response arrived, such as **Last response received 5m ago**, or **No responses received from Typeform yet.** before the first one. If you've submitted a test response and the line hasn't changed after a minute, check the form's webhook in Typeform. To stop, turn the switch off and confirm. big removes the webhook from Typeform and stops accepting deliveries for that form. Responses big is still holding for the form, such as ones waiting for you to import it, are dropped, and new responses stay in Typeform. Disconnecting Typeform stops intake for every form. A workspace can receive responses from up to 50 Typeform forms. A form that another big workspace already receives responses from can't be turned on here, because Typeform lets big register only one webhook on a form; big says so instead of taking the form over. Turning a form off in one workspace never removes the webhook another workspace relies on. Turning intake on sends submissions made from then on. To bring in the responses a form collected before that, use **[Back-fill past responses](#back-fill-past-responses)**. **Answers big can't store.** A received answer that doesn't fit its big question is left out, and the rest of the response is still saved. An *Other* answer is kept when the big question takes an [Other answer](/docs/guides/forms/field-types#other-answers), which an import sets up for every Typeform question with an *Other* option. On a form imported before that, re-import it to pick up the Other answers, or, if the re-import is refused, tick **Allow an Other answer** on the question in big: until then, a Multiple choice question keeps the options the person ticked and drops only their Other text, and a Single choice question answered with Other is left blank. ## Back-fill past responses Once a form is receiving responses, an admin can bring in the responses it collected before intake was turned on. On **Forms → Import**, go to step 2, **Back-fill past responses**, and choose **Start back-fill**. big reads the form's completed responses from Typeform, newest first, up to the moment you start the back-fill, and adds each one to the imported big form's **Responses** tab. It works in the background, about 200 responses every five minutes, so a form with thousands of responses takes a few hours. The line under the button shows how far it has got, with a bar when Typeform has said how many responses there are, such as **Back-filling: 120 of 340 stored, 3 skipped.**, and **Back-fill done** once it has read the whole history. * **Each response is stored once.** A response big already has, from the webhook or an earlier back-fill, is skipped. That also means a back-fill catches any response the webhook missed. Back-filling the same form again adds nothing new. * **Only finished responses.** A response someone started and didn't submit is skipped. * **Back-filled responses don't count toward your plan.** They never count against the [weekly usage cap](/docs/guides/account/plans#the-weekly-usage-cap) and are never locked. * **No action items.** A back-filled response doesn't add an intake card to your Action items board, so a long history doesn't fill it with cards. * **Clients.** On a form that [creates clients from responses](#create-clients-from-responses), back-filled responses are matched to clients by email and can add applicants, the same as new responses. * **Erased clients stay erased.** A response submitted on or before a client was erased is never brought back. **Do your application form first.** Back-fill the form that creates your clients before any form set to **Who fills it in → [Existing clients](#forms-your-existing-clients-fill-in)**, so their past responses can match the clients the application form creates. Step 2 shows this reminder on a form until it has been back-filled. **If it pauses or stops.** Typeform limits how fast big can read responses. When big hits that limit, the line says **Paused by Typeform's rate limit**, and big carries on from where it stopped about five minutes later. If Typeform asks big to reconnect, the form stops receiving responses or is removed from big, or another big workspace starts receiving the form's responses, the back-fill stops and says why. Reconnect or fix the form, then choose **Start back-fill** again. Responses already stored are skipped. Back-filling needs the **admin** role, and it can only be done in the dashboard. API tokens, the CLI and connected agents can read back-filled responses like any other response, but can't start a back-fill. A form that is your [client check-in form](#use-a-typeform-form-for-client-check-ins) can't be back-filled. ## Create clients from responses If your workspace keeps client records, each form has a **Create clients from responses** switch at the top of the form's page. It works the same for Typeform forms you receive responses from and for big's own forms. Changing it needs the **editor** role, and it can only be done in the dashboard. * **On:** every response is matched to a client by email. If there's no match, big adds a new applicant with that email. * **Off:** a response is still linked to an existing client with the same email, but big doesn't add new clients. Matching runs about every five minutes. On **Forms → Import**, a Typeform form that is receiving responses shows a **Create clients from responses →** link under its title that takes you to the switch on its imported big form. ## Forms your existing clients fill in Some forms are filled in by people who are already your clients, such as a revamp or re-onboarding form. On **Forms → Import**, an admin sets step 3, **Who fills it in**, to **Existing clients** on a form that is receiving responses and is imported into big. **Anyone**, the default, means a response can add a new applicant when Create clients from responses is on. * **Never creates clients.** Each response is matched to a client by email, as usual, but big never adds a new client from it. Choosing **Existing clients** turns the form's [Create clients from responses](#create-clients-from-responses) switch off, and the switch can't be turned back on until you choose **Anyone** again. * **Marked as unverified in Notion.** A matched response's page in the [Form responses](/docs/client-records/notion#form-responses) database says **Unverified (matched by email)**, because an email alone doesn't prove the response came from that client. That is true of a response matched by email on any form; only a response that created its client, or was sent through the client's own link, says **Verified**. **Needs work** asks you to check it. * **Never changes the client's chart.** A matched response is linked to the client and nothing else about the client changes. **For ongoing revamps, use the client's update link instead.** Matching by email is the best big can do for past responses. For new ones, add the `big_update` hidden field to the form and send each client their own link, as in [Use a Typeform form for client check-ins](#use-a-typeform-form-for-client-check-ins): every submission is then tied to the right client by their link, not by the email they type. That is a change you make to the form in Typeform; big doesn't make it for you. ## Choose which answers reach Notion If your workspace has Notion connected, each response matched to a client gets a page in the [Form responses](/docs/client-records/notion#form-responses) database. By default that page shows **no answers**. On **Forms → Import**, step 4, **What goes to Notion**, lists the questions whose answers are shared, such as **5 of 27:** followed by their labels, or **No answers go to Notion.** when none are, so you can check what reaches Notion without opening anything. To change it, an admin chooses **Choose answers** on a form that is receiving responses and is imported into big. A dialog opens with every question on the form, under a reminder that nothing reaches Notion until you tick it: * Tick the questions whose answers the page may show. The count at the top, such as **3 of 27 selected**, follows your ticks, and **Select all** and **Select none** tick or clear the whole list. * Choose **Save answers** to keep the change. Nothing changes in Notion until you save. * **Cancel**, the close button or Escape with unsaved ticks asks **Discard unsaved changes?** first. Choose **Keep editing** to go back, or **Discard** to close, and Notion keeps the answers it had. What the choice means: * Only the ticked answers appear, in the page's body. Every other answer stays in big, on the form's **Responses** tab. * Leave out anything medical or private. Everyone who can open the Form responses database in Notion can read the answers you tick. * Unticking a question removes its answer from every page of that form on the next syncs. * If a ticked question is renamed or changes type, in big or by re-importing the form, its answers stop going to Notion. Step 4 shows a badge such as **2 need re-approval**. In the dialog, the question is listed under **2 answers need re-approval** and marked **Changed**. Tick it again and save to share it. * Answers can be chosen on up to 200 forms. Clear the answers of a form you no longer use to choose them on another. * File uploads are never imported, so a file never reaches Notion. Setting who fills a form in and choosing its answers need the **admin** role and can only be done in the dashboard. API tokens, the CLI and connected agents can't change them. ## Use a Typeform form for client check-ins A coaching practice can collect client check-ins with its own Typeform form instead of big's ready-made **[Client check-in](/docs/client-records/check-in-form)** form. Each client's link in the **Update link** column of your Clients board in Notion then opens your Typeform form, and every submission adds a client update to that client, the same as a check-in through big's form. There's no switch to flip in big: big finds the form by a hidden field. ### Set up the form 1. **Connect Typeform** if you haven't (see above). The connection needs the response and webhook permissions, so approve once more if Typeform asks. 2. In Typeform, open the form's **Logic → Hidden fields** and add a hidden field named exactly `big_update`. It tells big that the form is your check-in form, and it ties each submission to the right client. 3. Give each number question one of these question references (in Typeform, the question's **Question reference** under its settings): | Question reference | Records | | ------------------ | ------------------------------------------------------- | | `weight_kg` | Weight, answered in kilograms | | `weight_lb` | Weight, answered in pounds (big stores it in kilograms) | | `body_fat_pct` | Body fat, 2 to 75 % | | `sleep_hours` | Average sleep per night, 0 to 24 hours | | `daily_steps` | Average daily steps, up to 100,000 | | `adherence_pct` | How closely the client followed the plan, 0 to 100 % | Use a **Number** or **Opinion scale** question for these. Ask for weight with only one of `weight_kg` or `weight_lb`: the unit comes from the reference, so the client doesn't pick one. A number from any other kind of question, or under any other reference, goes into the client update note as text and is never recorded as a metric. 4. Add any text questions you like, such as **How did the week go?**, **Wins** and **Struggles** (references `week_summary`, `wins` and `struggles` are a good choice). Their answers go into the client update note. 5. Publish the form. big checks your Typeform forms about every 15 minutes. Once it finds the form, it registers a webhook on it, and on its next run each client's **Update link** cell changes to a link that opens your Typeform form. Clients who already have big's link get the new one in that run too, so send them the new link. ### How it behaves * **One check-in form per workspace.** If several forms declare `big_update`, big uses the most recently updated one. A newer form replaces the current one when you add the hidden field to it. * **A form you already receive responses from** becomes your check-in form when you add `big_update` to it: from then on its submissions are client check-ins, and it **stops storing responses and creating applicants**. Remove the hidden field and it goes back to being an ordinary form you receive responses from, on big's next check. * **The form is never imported.** A check-in form big found by itself doesn't appear on your **Forms** list, and its submissions never become responses. * **On Forms → Import** the check-in form's **Receive responses** switch is on. Turning it off turns Typeform check-ins off and big goes back to its own form. To use the Typeform form again, edit and republish it so big finds it on its next check. * **Each check-in counts once.** If Typeform sends the same submission twice, big records it once. * **Removing the form.** Remove the hidden field, delete the form or disconnect Typeform, and big goes back to its own check-in form: every **Update link** cell changes to big's form on its next run. * **A form another big workspace already uses** is skipped: big never moves its webhook, so that workspace keeps receiving its submissions, and your current check-in form stays in place. * **A submission without the client's link code** (someone opening the form's plain address) is discarded and stores nothing in big. It still counts as a response in Typeform. ### Typeform response limits Typeform plans limit how many responses a form can collect, and every submission counts, including ones big discards because they came without a valid link code. So a link that gets passed around can use up your Typeform responses. See Typeform's pricing page for your plan's limit. big's own check-in form has no response limit, which is why big uses it unless you set up a Typeform form. --- # Form versions > Source: https://itsjustbig.com/docs/guides/forms/versions · Last modified: 2026-10-02T00:00:00.000Z Forms change. You reword a question, add a page, drop a field that wasn't earning its place. The problem that creates is in your **results**: if a response is shown against today's form, an answer given six weeks ago gets read under a question that no longer exists — or worse, under a different question that happens to sit in the same spot. big solves that by keeping a **version** of your form every time its questions change, and stamping each response with the version it was answered on. ## How versions are created * **Saving changes** to your form's questions creates a new version automatically and makes it live. You don't have to remember to snapshot anything. * **Renaming the form or changing its status** doesn't create a version — nothing about the questions changed. * **Saving without making changes** creates nothing. * **Changes from the CLI, the API or a connected agent** create a version the same way. One limit applies there: they **can't rewrite the questions of a live form**. A token that tries is refused and told to send the new questions together with a move back to draft, then publish the new version, which asks a person to approve it. Renaming a live form and turning identity syncing on or off still work. * **Re-importing from Typeform** creates a version too, and never overwrites in place. If the form has picked up pages, branching or a custom thank-you screen in big since it was imported, the re-import is refused rather than flattening them back into Typeform's single list of fields. * **Save as version** does the same thing as a normal save, but lets you give the version a **name** — "before the spring rewrite", "short version for stories" — so you can find it later. Versions are numbered in order (v1, v2, v3…) and named ones show their label alongside. ## Going back to an older version Open the version list on your form and choose **Set active**. That version's questions become the live form immediately, and anyone who opens your public link from that moment sees them. Setting an old version active doesn't erase anything in between — those versions stay in the list, and the responses collected under them stay attached to them. **Duplicate version** copies an older version into a new one *without* making it live. Use that when you want to build on an old draft: duplicate it, edit it, then set it active when you're happy. ## A version isn't the same thing as publishing The two are easy to run together, and they answer different questions: * A **version** is a snapshot of your **questions** — what was asked, so an answer is always read under the question it was given for. Saving a change to the questions makes a new one. * **Publishing** is about whether the form is **reachable at all**: `draft`, `active` or `closed`, on the `/f/` link. It says nothing about which questions are live. A form can go through ten versions while never leaving draft, and a live form keeps the same public link across every version it has ever had. One thing follows from that split. **Taking a form live from outside the dashboard now needs a person.** The CLI, the API and a connected AI agent can ask to publish a form, and the request produces a short code that someone signed into big has to enter before the form goes live — the same approval a link page needs, for the same reason. The code is entered on the form's own **Approve a form publish** screen (`/forms/
/approve`), which lists every question of the version that would go live; a code typed anywhere else approves nothing. In the dashboard it stays one click: you are already the person the code would have gone looking for. Setting a different version active isn't publishing and doesn't ask for a code — it changes the questions on a form whose status you already chose. ## What this means for your results * **Responses** show which version each person answered. A question that didn't exist in someone's version is shown as *not asked* — clearly different from a question they were asked and left blank. * **Stats** can be read per version, so you can answer the question that actually matters: *did the change help?* Shorten a form from five pages to three and you can compare the finish rate before and after, instead of averaging two different forms together. * **[Drop-off](/docs/guides/forms/stats)** is tracked per version too. Since pages get added and reordered, drop-off numbers pinned to a version stay meaningful — otherwise editing a form would silently rewrite the history of every number. ## Your public link never changes Versioning is invisible to the people filling in your form. Your `/f/` link stays the same, it always shows the live version, and switching versions doesn't break a link you've already shared. ## Good to know * **Versions are read-only snapshots.** You edit the live form; you don't edit an old version in place. To change an old one, duplicate it first. * **Existing forms already have a v1.** Everything created before versioning was added is recorded as v1, and every response already collected is attached to it. * **Deleting a version** doesn't delete the responses collected under it — those responses simply stop being tied to a stored definition and fall back to the live one. * **Deleting the form does delete everything.** Every version, every response, the whole funnel history. That is the one action on a form that erases what it has collected, and it can't be undone — see **[Delete a form](/docs/guides/forms#delete-a-form)**. --- # Campaign attribution > Source: https://itsjustbig.com/docs/guides/links/attribution · Last modified: 2026-09-14T00:00:00.000Z big records where each visit came from — the placement you copied the link for, the campaign tags on the URL, and the site that referred it — so you can tell which post, platform, or promo is actually doing the work. Most of the time you don't set any of that up. You pick where you're posting at the moment you copy the link, and big handles the rest. ## Copy a tagged link Open a link's stats page and find the **Copy a tagged link** box. 1. Under **Where**, pick the placement you're about to post to: Instagram bio, Instagram story, Instagram post, TikTok bio, YouTube description, Newsletter / email, X (Twitter), Facebook, LinkedIn, Pinterest, or Other. 2. Optionally type a **Campaign** name — `spring-sale`, `black-friday`. Leave it blank if this is just your everyday bio link. 3. Hit **Copy link**. What lands on your clipboard is an ordinary-looking big link: ``` itsjustbig.com/l/k3f9x ``` No parameters, nothing to explain, nothing that reads as tracking. It sends people to exactly the same destination as the link you started from — the campaign tags are held on big's side and applied when someone clicks. Pasted into a bio or a story, it's indistinguishable from any other big link, and every click through it is filed under the placement you picked. **Copying the same placement again gives you the same link back.** big doesn't mint a fresh code each time you hit copy, so re-posting your story every week keeps all of those clicks on one row instead of splitting one placement across five codes. Change the campaign name and you get a different link, because that's a different thing you're measuring. Tagged links don't clutter up **Links → Short links** — they belong to the link you made them from rather than standing on their own, and deleting that link removes them with it. ## Your destination still sees the tags The clean-looking URL is about big's link being presentable, not about withholding data from anyone. When someone clicks, big applies the stored tags on the way through, so the site on the other side receives them as normal `utm_source`, `utm_medium`, and `utm_campaign` parameters. Google Analytics, Shopify, or whatever you're sending people to attributes the visit exactly as it would if you'd typed the parameters yourself. If the destination URL already carries a parameter of its own, its value wins — the full passthrough rules are in **[Short Links](/docs/guides/links)**. ## Links sent in DMs are tagged for you Links that an automation sends in a DM are recognized by big when they're clicked. There is nothing to pick and nothing to configure — put the plain short link in your automation as you always have. Those clicks are attributed to the platform the conversation is on — **Instagram** for an Instagram DM, **Facebook** for a Facebook Page (Messenger) conversation — with a medium of `dm`, instead of falling into Direct. This is the one place where tagging genuinely can't be forgotten, and it matters because DMs are where a lot of creator traffic actually lives. Two honest edges: * It covers big short links in the **text** of a message, in a quick-reply message, and on the **link buttons** of a card or carousel. A link to another site is left exactly as you wrote it, and a public reply under a comment is never tagged, because anyone can read it. * Recognition lasts **72 hours** from when the message was sent. People do open message requests days late; past that window the click still counts, it just counts without the DM attribution. If you send a tagged link through a DM, the placement you chose wins — big won't overwrite your choice with `dm`. ## What gets recorded Tags are recorded on three things: **link clicks**, **form views**, and **form submissions**. That last one is the useful part — see [From clicks to leads](#from-clicks-to-leads). Public form links can be tagged too. There's no channel picker on a form link, so you add the parameters yourself: ``` itsjustbig.com/f/summer-signup?utm_source=instagram&utm_campaign=spring ``` ## Channels, not hostnames Raw referrers are messy. Instagram alone sends traffic from `instagram.com` and `l.instagram.com`, which would otherwise sit in your stats as two or three separate rows that all mean "Instagram." So big classifies each visit into a single **channel** — Instagram, TikTok, Google, Email, Direct, and so on — using the campaign tag first and the referring site as a backup. One platform, one row. Hops between your own big pages get their own channels rather than Direct or Other: a tap on a link-page button counts as **Link page**, a visit that came from one of your forms counts as **Form**, and a form's confirmation sending people on to your link page counts as **Form** too. Your link page shows up as a source in its own right. **Direct** is not a channel so much as the absence of one. It means big had no signal at all: someone typed the URL, opened a bookmark, or came from an app that strips the referrer. It is not a synonym for "typed it in." ## Tagging is what makes it reliable This is the honest part, and it matters more than anything else on this page. Attribution from referrers alone is unreliable, because referrers go missing constantly. Links opened inside an app — Instagram's in-app browser, DMs, WhatsApp, iMessage — very often arrive with no referrer at all. Since messaging apps are exactly where creators share links, this isn't an edge case. The practical consequence: **real Instagram traffic will land in Direct if the link wasn't tagged.** big isn't guessing, and it won't invent a source it doesn't have. A tag is a signal you control, so it survives all of that. What's changed is the price of it. Tagging used to mean pasting `?utm_source=instagram&utm_medium=bio` into your bio — accurate stats in direct tension with a link you'd actually want to show people, and the link usually won. That tradeoff is gone. The tagged link you copy looks like every other big link, so there's nothing left to weigh: pick the placement, paste the clean link, get the right channel. What this does **not** mean is that attribution is now automatic across the board. It's automatic for links sent in DMs, and it's handled for you on any link you copy through the picker. A link you share some other way — pasted from your browser bar, forwarded by someone else, copied out of an old post — carries no tag, and Direct will quietly absorb it. ## Tagging by hand Manual UTM parameters work exactly as they always have, and they're still the right tool in two cases: you're sharing the link somewhere big's copy button wasn't involved, or you want a source or campaign the picker doesn't offer. Add the parameters to the end of the link before you post it: ``` https://itsjustbig.com/l/abc?utm_source=instagram&utm_campaign=spring-sale ``` A convention that holds up: * **`utm_source`** — *where you posted it*. `instagram`, `tiktok`, `newsletter`, `podcast`. * **`utm_campaign`** — *the name of the promo*. `spring-sale`, `black-friday`, `launch-week`. If the link already has a `?` in it, join the extra parameters with `&` instead. **Spell them the same way every time, in lowercase.** `Instagram` and `instagram` are two different values, so an inconsistent capital letter splits one campaign across two rows and makes both look half as big as they are. Pick a spelling, write it down, reuse it. (This is the failure the picker exists to prevent — it always writes a spelling big recognizes.) You can also hand-tag a tagged link. Anything you put on the URL beats the tags stored behind it, so adding `?utm_campaign=black-friday` to your bio link reuses the placement and overrides just the campaign. ## From clicks to leads Because tags are recorded on form *submissions*, not just views, you can see which channel and campaign produced actual leads rather than just traffic. A submission takes its source in this order: 1. **Tags on the form page itself.** If the form URL the visitor submitted from carries campaign tags, those win. 2. **The big link that brought them.** Otherwise, if the visitor reached the form through one of your short links in the last 7 days in the same browser, the submission inherits that click's channel and campaign. This is how a lead from a DM link counts as Instagram (or Facebook) with medium `dm` instead of Direct, and how an untagged link-in-bio click keeps the channel big worked out for the click. 3. **Nothing.** A submission with neither counts as Direct. That's the difference between "TikTok sent 4,000 clicks" and "TikTok sent 4,000 clicks and 3 signups, while the newsletter sent 200 clicks and 40 signups." Traffic volume and lead quality rarely rank the same way, and only the second view tells you where to spend your time. Channel and campaign appear alongside your existing numbers in **[Form stats](/docs/guides/forms/stats)** — both on the workspace overview and on each form's own stats tab. ## Untagged links still work They just work less well. An untagged visit is classified from the referring site where one exists, and falls back to **Direct** where one doesn't. Nothing breaks and no clicks are lost — you simply get a coarser answer, and a larger Direct bucket than reality. ## What this can't tell you yet **A visitor's source doesn't follow them into their contact record.** Attribution is recorded per click, per view, and per submission — it is not yet stitched onto the person. So you can ask "which campaign produced the most leads last month" and get a real answer, but you can't yet open a single contact and see the campaign that first brought them in. That's a limitation of how attribution is stored today, not a setting to switch on. **Attribution is per visit, not a journey.** big remembers only the last short-link click in a browser, for 7 days, and only to fill in a submission that has no tags of its own. If someone clicks your Instagram link on Monday and submits the form on Thursday in the same browser, the submission counts as Instagram; on another device, or after a week, it counts as Direct. A visitor who opened the form URL directly from an untagged post (not through a short link) also counts as Direct, even though the form view shows where they came from. big does not model multi-touch attribution. ## What's excluded Bots and link-preview fetchers are excluded here exactly as they are in [link stats](/docs/guides/links/stats) — the automated fetch an app makes to build a link preview never creates a channel row. ## Privacy big never stores your visitors' raw IP addresses. Campaign tags are marketing metadata — they describe where a link was posted, not who clicked it — so nothing on this page identifies an individual visitor. Everything here is counted from your own workspace's records. ## How fresh is this Attribution is recorded at the moment of the click, view, or submission, and the breakdowns are computed live when you load the page. There's no overnight batch and no precomputed rollup. --- # Short Links > Source: https://itsjustbig.com/docs/guides/links · Last modified: 2026-09-21T00:00:00.000Z > **Short links** and **[link pages](/docs/guides/trees)** sit side by side under **Links** in the sidebar: a short link is one redirect at `/l/`, a link page is one hosted page at `/t/` holding many buttons. A link is a short redirect at `/l/:code` that sends visitors to a target URL of your choice, with click stats tracked automatically. ## What a link is Every link has a target URL and a code. Visiting `itsjustbig.com/l/` redirects instantly to the target. Stats for total clicks, unique clicks, referrers, and devices are tracked per link — see **[Link stats](/docs/guides/links/stats)**. ## Create a link Create links from **Links → Short links** (requires editor role): * **Target URL** — required. Must be an absolute `http://` or `https://` URL. * **Code** — either auto-generated at random, or a custom alias you choose. A custom alias can use letters, numbers, and hyphens, up to 32 characters, and must be globally unique across all workspaces — big checks availability as you type. Aliases are stored in lowercase, so `Sale` becomes `sale`. * **Display name** — optional, up to 80 characters, shown to you in the dashboard. To tie a short link to a form (so its clicks count as part of that form's share flow), don't create it here — use the **Shorten it →** button in the form editor instead. See **[Share your form](/docs/guides/forms/sharing)**. ## Links created for you Two other parts of big mint short links without you typing them: * **Forms.** The **Shorten it →** button in the form editor attaches a link to a form. These are listed like any other link, with a form chip — you asked for that one, so it's yours. * **Link pages.** Each link button on a **[link page](/docs/guides/trees)** gets its own short link on save — that's how per-block click counts work. **These are not listed by default.** **Links → Short links shows the links you created there.** A link page's buttons belong to the page, not to this list: you read their click counts on the page's **[Stats](/docs/guides/trees/stats)** tab, and their `/l/` code is shown next to each block there. Otherwise you'd open Short links and find a pile of random codes you never made and can't place. ### Seeing them anyway Above the list, **Show them too** switches to every short link in the workspace — page-minted ones included, plus any left over from a page or block you removed. The same switch works over the API: ``` GET /api/links # the default: links you created GET /api/links?scope=all # everything, page-minted and leftovers included ``` The response echoes back the `scope` it applied, so you never have to guess which slice you got. `big links` and the MCP link tools list the default scope. Which is which is readable per row: `bio_page_id` says a link page minted it, `form_id` says a form did, and `orphaned_at` says the page or block that owned it is gone. ### How page-minted links behave * **The link is retargeted, not replaced, when you edit the block's URL.** The code stays the same and its click history carries over — deliberately, so fixing a typo or swapping a campaign destination doesn't reset your numbers. This is the one case where a link's target *does* change. * **Deleting the link page (or removing the block) doesn't delete the link.** The code keeps redirecting and keeps its history. It's flagged as no longer belonging to a page, which is why it drops out of the default list — switch to **Show them too** to find it, and delete it there if you want the redirect gone. * **Deleting one of these links doesn't break the page it came from.** The block that referenced it is simply left off the public page from then on — see **[Blocks](/docs/guides/trees/blocks)**. ## What's not there yet * **No editing a link you created by hand.** The alias, name, and target of a link created in **Links → Short links** are all fixed once it exists. To change any of them, create a new link, then delete the old one if you no longer want it; the new link needs a different code, because a deleted code is never reused (below). (Links minted for a link page are the exception — see above.) * **Deleting is permanent, and the code is retired.** Deleting a link also permanently deletes its click history. Its code, and every tagged copy of it, can never be created again, by you or by anyone else, so a QR code or a DM that already carries it can't be pointed somewhere new. Anyone opening it gets a "not found" page. * **No caps.** There's no plan-based limit on how many links you can create or how many clicks they can receive. ## The redirect itself Visiting `/l/:code` returns an instant redirect to the target URL — every hit is tracked. If the code doesn't match any link, the visitor is simply redirected to the big homepage; there's no error page shown. One exception: a link that lands on **OnlyFans or Fansly** shows an age check first, and the click isn't counted or attributed until the visitor confirms they're 18 or older. It applies wherever the link was opened from, and to links minted for a link-page button as well as ones you made yourself — see **[Sensitive content](/docs/guides/trees/sensitive-content)**. ## Campaign tags pass through Anything you append to a big link travels on to the destination. Share: ``` https://itsjustbig.com/l/abc123?utm_source=instagram&utm_campaign=spring ``` …and the visitor lands on your target URL with `utm_source` and `utm_campaign` still attached, so Google Analytics — or whatever the destination runs — attributes the visit correctly. big forwards **campaign parameters specifically** — the `utm_*` family plus the major ad-platform click ids (`gclid`, `fbclid`, `msclkid`, `ttclid`, and similar). Other parameters are not passed on. That's deliberate: a link you share is something strangers can edit before re-sharing, and forwarding anything at all would let them append parameters that change how the destination behaves. You usually don't have to type them. Pick where you're posting when you copy the link and big hands you a clean, already-tagged link — see **[Campaign attribution](/docs/guides/links/attribution)**. Two rules worth knowing: * **The target's own parameters win.** If you created the link pointing at `shop.example.com/sale?utm_source=big`, then someone clicking `...?utm_source=twitter` still arrives with `utm_source=big`. Your link's own tagging can't be overwritten by editing the URL. * **big's internal tracking parameter is never forwarded.** When an automation DMs one of your links, big adds a private parameter so it can [link the click back to that conversation](/docs/guides/forms/responses). That value identifies a specific recipient, so it's consumed at the redirect and never passed on to the destination. --- # Link stats > Source: https://itsjustbig.com/docs/guides/links/stats · Last modified: 2026-09-21T00:00:00.000Z Every link has its own stats page showing how it's performing over time. ## Preset ranges The stats page shows five period tiers side by side — **day**, **week**, **month**, **quarter**, and **year** — so you don't pick one; you see all of them at once. Each shows: * **Total clicks** for the period. * **Unique clicks** — distinct visitors, tracked with a daily-rotating hash rather than raw IP addresses (see [Privacy](#privacy) below). * **Change vs. the previous period** — but compared to the *same elapsed slice*, not the whole prior period. For example, if you're 12 days into the current month, the comparison is against the first 12 days of last month, not all of last month. This keeps in-progress periods from looking artificially down against a completed one. ## Custom range Prefer specific dates? Use the date range picker to pick any start and end date. Your custom range is compared against an equal-length range immediately preceding it. ## Breakdowns These cover the link's **entire history** (since it was created) — unlike the click counts above, they aren't scoped to the five period tiers. * **Top referrers** — where clicks came from. Clicks with no referrer (typed directly, bookmarked, or opened from a DM) show as **(direct)**. The 50 biggest referrers are listed by name and the rest are added up in one **(other referrers)** row, so the list always adds up to the link's total. * **Device & browser** — a split across mobile, tablet, and desktop, and across browsers like Chrome, Safari, Firefox, and Edge. This also adds up to the total. The API and MCP `link_stats` also return each placement's `utm_medium` beside its channel and campaign, so an Instagram bio link and an Instagram story link stay apart. ## What's excluded Bots and link-preview fetchers (the automated requests apps make to generate a link preview) are excluded from every count above — they never inflate your clicks. So are browser and framework **prefetches**: when a page loads a link in the background before anyone taps it, the visitor still gets redirected, but nothing is counted until they actually tap. So is a visitor who met an **[age check](/docs/guides/trees/sensitive-content)** and left without confirming. They never reached the destination, so counting them would overstate this number rather than fill it in. A confirmed click counts once, with its campaign tags intact. ## Privacy big never stores your visitors' raw IP addresses. Unique-click counts are powered by a hash that rotates daily, so it can't be used to correlate the same visitor across different days. ## How fresh is this Stats are computed live when you load the page — there's no plan-based cap on links or clicks, and no precomputed daily rollup behind the numbers. Every view reflects the current data. --- # Scheduling posts > Source: https://itsjustbig.com/docs/guides/scheduling · Last modified: 2026-10-19T00:00:00.000Z **In testing, not available yet.** Scheduling is in testing and visible only to big's team, so **Schedule** does not appear in your dashboard yet. This page describes how it will work once it opens. **Publishing is not switched on yet.** You can plan, write, approve and schedule posts today. They go out once Instagram publishing is approved for big, and every scheduling screen says so until then. Scheduling lives at **Schedule** in the dashboard (`/schedule`). It is **dashboard-only for now**: the CLI, the MCP servers and API tokens cannot read or change scheduled posts yet, and a token call is refused with a sentence that says so. ## Planning posts A **post** is one piece of content you plan once and send to one or more of your connected accounts. Each account gets its own version of the post, so you can tune the caption or media per account while keeping them together. A post moves through these states: * **Draft**: being written. Nothing is scheduled. * **Awaiting approval**: an editor scheduled it in a workspace that requires approval, and it waits for an admin. * **Scheduled**: approved and waiting for its time. * **Published** or **Failed**: shown per account once big tries to publish it. If one account fails, the whole post shows as failed so a partial failure is never hidden. * **Cancelled**: it will not be published. You can still read it. ## The calendar The calendar shows a month at a time, Sunday first, in your own timezone. Each post is a chip with its local time, its platforms, a caption preview and its status. Use the arrows to move between months or **Today** to come back. Drafts with no time yet sit in the **Unscheduled drafts** rail beside the calendar. Editors and admins see **New post**; viewers can open any post to read it. ## The composer Open a post or choose **New post** to use the composer: 1. **Pick the accounts** to post to. Each account becomes its own version of the post. 2. **Choose a post type** for each account, such as a feed image, a carousel or a reel. Only the types that account's platform supports are offered. 3. **Write the caption** within the platform's limit, and **attach media** from **[Files](/docs/guides/files)**. Only files that suit the post type are offered, and only files in this workspace. 4. **Set the time**, in your local time, and add a note for your team if you like. 5. **Save draft** to keep working, or **Schedule** to queue it. When your workspace requires approval and you are an editor, the button reads **Submit for approval**. Problems with a version show as you type, and big checks every version again when you schedule. **Editing a scheduled or pending post moves it back to draft.** Any change gives the post a new revision and clears its approval, so nothing publishes that nobody reviewed. big asks before **Save draft** does this; schedule it again when you are done. **Once any account has published, the post is locked.** You can still cancel the accounts that have not gone out yet, but you cannot edit or delete the post, so the record of what was published stays intact. To post something different, cancel it and create a new post. **If every account failed, you can try again.** Nothing went out, so the post stays editable: fix what failed (reconnect the account, or change the post), which moves it back to draft, then schedule it again. ## Approval An admin can turn on **require approval** in **Settings**, beside your team members. When it is on: * Posts an **editor** schedules wait in the **Approvals** queue (linked from the calendar, with a count). * **Admins and owners** schedule directly. * An admin approves the exact version they were shown. If someone edits the post after the queue loaded, the approval is refused and the admin reviews it again. * An admin can also send a post back to draft. Roles are described in **[Team](/docs/guides/account/team)**. ## Plan limits Each plan allows a number of scheduled posts per calendar month, counted per account the post goes to: one post sent to two accounts counts as two. | Plan | Scheduled posts per month | | ------------ | ------------------------- | | teeny (free) | 10 | | tiny | 60 | | big | 300 | | bigger | Unlimited | The month is the one the post is scheduled for. At the limit, scheduling is refused with a link to upgrade. Downgrading never cancels what is already scheduled. See **[Plans](/docs/guides/account/plans#scheduled-posts)**. ## Deleting your account Deleting the account cancels every post still waiting to publish before any of your data is removed. See **[Your data](/docs/guides/account/your-data)**. --- # Calendly > Source: https://itsjustbig.com/docs/guides/integrations/calendly · Last modified: 2026-09-30T00:00:00.000Z Connecting Calendly lets big see the bookings side of your business: the calls people schedule with you. You connect it with a Calendly **personal access token**. ## Calendly tokens are not scoped **Calendly personal access tokens can't be limited to part of your account.** A token has the same reach as the Calendly user who created it, so there is no narrower token to create. big says so on the connect screen as well. What you can control: * **Which Calendly user creates the token.** It reaches what that user can reach, so create it as the user whose bookings you want big to see. * **Its name.** Call it something that says it is for big, so you know which one to delete if you ever disconnect or rotate. * **What big does with it.** big only reads, and a key saved in big can't be read back by anyone. See **[Integration security](/docs/guides/integrations/security)**. ## Create the token 1. Sign in to Calendly as the user you want to connect. 2. In Calendly, open **Integrations → API and webhooks** and choose to generate a new **personal access token**. Calendly's own help at [calendly.com](https://calendly.com) has the current steps if the menu has moved. 3. Name it, for example "big", and copy it. Calendly shows it only once. ## Connect it in big Open **Connect → Integrations → Browse catalog**, choose **Calendly**, paste the token and save. big tests it with one read-only call that asks Calendly who the token belongs to, and shows that Calendly user once it is connected. The full walkthrough, including rotating and disconnecting, is **[Connect an integration](/docs/guides/integrations/connect)**. ## When you rotate or disconnect big can't revoke a Calendly token. After rotating or disconnecting in big, delete the old token in Calendly's **API and webhooks** settings. --- # Connect an integration > Source: https://itsjustbig.com/docs/guides/integrations/connect · Last modified: 2026-10-02T00:00:00.000Z Everything on this page happens in the dashboard and needs the **admin** role or higher. Members below admin see the same screens without the controls. There is no way to connect, reconnect, rotate or disconnect from the CLI, the API or an MCP tool. Tools connect one of two ways: * **With an API key** you create in the tool and paste into big: **[Calendly](/docs/guides/integrations/calendly)** and **[Discord](/docs/guides/integrations/discord)**. See **[Connect with an API key](#connect-with-an-api-key)**. * **By signing in** to the tool and approving big's read-only access (OAuth), with nothing to paste, for the few integrations big sets up for specific workspaces. See **[Connect by signing in](#connect-by-signing-in)**. ## Connect with an API key 1. Open **Connect** in the sidebar, find the **Integrations** section and choose **Browse catalog**. 2. Pick the tool you want to connect. Its screen says which kind of key to create and how to keep it as narrow as the tool allows. The per-tool pages have the same guidance: **[Calendly](/docs/guides/integrations/calendly)**, **[Discord](/docs/guides/integrations/discord)**. 3. Create the key in that tool, then paste it into big. Give the integration a **label** you'll recognise later, for example "Sales Calendly". 4. Save. **big tests the key before it stores anything.** It makes one read-only call to the tool with the key you pasted: * If the tool accepts it, the key is encrypted and saved, and the integration shows as **Connected** with the account the key belongs to. * If the tool rejects it, or the key is broader than big allows, **nothing is saved** and you see a short explanation. Fix the key and try again. * If the tool is down or busy, nothing is saved and you can simply retry. Once saved, the key is never shown again, to you or anyone else. The integration's page shows its **last 4 characters** and a short **fingerprint** so you can tell which key is in use. See **[Integration security](/docs/guides/integrations/security)**. Every connect, rotate or re-verify tests a key, and testing is limited in two ways: **10 attempts per minute per person**, so a mistyped key can be retried straight away, just not in a tight loop; and a **daily limit per workspace**, across all its admins. Connecting and re-verifying share **30 key tests a day**; once the workspace reaches it, they are refused until tomorrow. Rotating has its **own 20 a day**, so using up the connect and re-verify limit never stops you replacing a leaked key. Disconnecting tests nothing, so it is never limited. A **suspended** workspace can't connect, rotate or re-verify an integration. ## Connect by signing in A tool you sign in to never takes a pasted key. big holds a sign-in token that the tool issues when you approve big, and big renews it on its own while the connection is healthy. 1. Open **Connect → Integrations → Browse catalog** and pick the tool. Its screen lists exactly what big will be able to read. 2. Choose the tool's **Connect** button. big sends you to the tool. 3. Sign in there, choose the account, and approve big's read-only access. 4. The tool sends you back to big's **confirm screen**. It shows: * **The account id** as the main line, and the account's name smaller underneath. The account's owner chooses its name, so check the id. * **LIVE** or **TEST**, for a tool that has test accounts, so you know which mode you approved. * **What it replaces**, if the workspace already has an integration for that tool, with the old and the new account ids. 5. Choose **Connect** to save it, or **Cancel** to throw it away. The confirm screen lasts **15 minutes**. Nothing is saved until you confirm, and only the admin who started the connection, signed in to big in the same browser, can confirm it. Before saving, big makes one read-only call with the new access to check it really belongs to the account the tool named. Each account at a tool can be connected to **one big workspace at a time**. If another workspace already holds it, connecting is refused and that workspace's admins are told; if that workspace's access has stopped working, your confirm frees the account and connects it to you. The connect button is hidden while big's connection to that tool isn't switched on. A suspended workspace, or one already at its plan's **[integration limit](#if-you-downgrade)**, is refused before you leave big, unless you are reconnecting a tool the workspace already has. ### Reconnect An integration you connected by signing in shows **Reconnect needed** when the tool stops accepting big's access, for example because big's app was uninstalled or removed from your account in the tool. Your admins get a notification and an email; see **[Notifications](/docs/guides/account/notifications)**. big stops calling the tool until you reconnect. Choose **Reconnect** on the integration's page and approve again. Reconnecting the **same** account brings the same integration back. Approving a **different** account replaces an integration that shows **Reconnect needed**, after you confirm, and doesn't take another slot on your plan. To swap a working integration for a different account, disconnect it first. ## Rotate a key Rotating applies only to tools you connect with an API key. An integration you signed in to has nothing to rotate; to replace its access, reconnect it. Rotate when a key may have leaked, when someone who had access to it leaves, or on your own schedule. 1. Create a new key in the tool. 2. Open the integration in **Connect → Integrations** and choose **Rotate**. 3. Paste the new key. big tests it exactly as it does on connect, and only replaces the old key once the new one works. If the test fails, the old key stays in place and keeps working. 4. **Delete the old key in the tool.** big can't do this for you: an API key can only be revoked in the tool that issued it. Until you delete it there, the old key still works for anyone who has a copy. The fingerprint changes when the key changes, so you can confirm the rotation took. ## Re-verify **Re-verify** re-runs the same read-only test against the key or access big already holds. Use it after fixing something in the tool, such as a key you re-enabled or a permission you added, to bring an integration in **Error** back to **Connected** without pasting the key again. An integration that shows **Reconnect needed** can't be re-verified; reconnect it instead. big also watches for a dead key on its own: after 3 rejections in a row, it moves the integration to **Error** and stops calling the tool with it, rather than hammering the tool with a key that no longer works. Re-verify, or rotate to a new key, to bring it back. ## Disconnect **Disconnect** deletes the stored key or sign-in token from big's live database **immediately**. There is no undo; to use the tool again, connect it again. A small record of the integration stays for your workspace's audit history: which tool it was, its label, the account, the dates, and a pasted key's fingerprint. It never includes the key, a token, or the key's last 4 characters. Whether the tool itself forgets big depends on the tool: * **An API key: delete the key in the tool too.** Disconnecting removes big's copy; it doesn't revoke the key where it was issued. * **A tool you signed in to: revoked where the tool allows.** Disconnect asks the tool to revoke big's access before deleting big's copy. If the tool has no revoke, remove big from your authorized apps in the tool. ## If you downgrade Moving to a plan with a lower **[integration limit](/docs/guides/account/plans#integration-limits)** never disconnects anything: * **The integrations you already have keep working** as before, and you can still re-verify, rotate and disconnect them. * **You can't connect a new one** while you are over the new plan's limit. Connecting is refused with a message saying so. * Disconnect the ones you don't need to get back under the limit, or upgrade. ## Check status from your agent or the CLI Anyone with a token carrying the `integrations:read` scope can see the same status the dashboard shows, including **Reconnect needed** (`needs_reconnect`), without a key ever being involved: * **CLI:** `big integrations list` and `big integrations status `. See **[the command reference](/docs/developers/cli/command-reference#integrations)**. * **MCP:** `integration_status` on the remote server, `big_integration_status` on the local one. See **[MCP](/docs/developers/mcp)**. * **API:** `GET /api/integrations/status`. See **[the API reference](/docs/developers/api-reference#integrations)**. All of them are read-only. Connecting, reconnecting, rotating and disconnecting are dashboard-only; credentials are never readable. --- # Discord > Source: https://itsjustbig.com/docs/guides/integrations/discord · Last modified: 2026-10-03T00:00:00.000Z Connecting **Discord** lets big see activity in your community server, so it can later show which clients are active and which have gone quiet. You connect it with a **bot token** from a Discord application you create. ## Use a bot made just for big big connects as a **bot**, never as a person. A personal account token is refused, because Discord's terms don't allow automating a user account. **Give the bot as little as Discord lets you.** Invite it with only **View Channels** and **Read Message History**. It does not need the **Message Content** intent, and it never posts. ## Create the bot 1. Sign in to the [Discord Developer Portal](https://discord.com/developers/applications) and create a **New Application**, for example "big". 2. Open **Bot** in the application and add a bot if it doesn't have one. 3. Open **OAuth2 → URL Generator**, tick **bot**, then tick only **View Channels** and **Read Message History**. Open the generated link and invite the bot to your server. 4. Back on the **Bot** page, choose **Reset Token** and copy it. Keep it somewhere safe only until you've pasted it into big. Paste the **bot token**, not the application's client secret. A bot token has three parts separated by dots. ## Connect it in big Open **Connect → Integrations → Browse catalog**, choose **Discord**, paste the bot token and the **Server ID**, and save. The Server ID tells big which server's activity counts: in Discord turn on **Developer Mode** (User Settings → Advanced), right-click your server's icon and choose **Copy Server ID**. big tests it with one read-only call that returns the bot's own name, and shows that bot once it is connected. The full walkthrough, including rotating and disconnecting, is **[Connect an integration](/docs/guides/integrations/connect)**. ## What big reads Once a day big counts, for each client you've linked to their Discord member, the messages they sent and the reactions they left in the server's text channels. Only who and when is stored, never what anyone wrote. Those counts drive each client's green, yellow or red engagement status. A client is linked to their Discord member once, by a coach; nobody is matched automatically. ## Link a client to their Discord member 1. In Discord, turn on **Developer Mode** (User Settings → Advanced), right-click the member and choose **Copy User ID**. 2. In big, open the client in **Clients** and paste the ID into the **Discord** card, then choose **Link member**. You need to be an editor or admin, and Discord must be connected first. A member can be linked to only one client; big tells you if that member is already linked to someone else. ## When you rotate or disconnect big can't revoke a Discord token. After rotating or disconnecting in big, reset the token on the **Bot** page in the Developer Portal, or remove the bot from your server. --- # Google Drive > Source: https://itsjustbig.com/docs/guides/integrations/google-drive · Last modified: 2026-10-17T00:00:00.000Z big can keep a read-only copy of the documents in your **Google Drive folders**, so you can search them in big and the AI tools you connect to big can read them. You share a folder with big once and link it in big; big then reads everything in it, including files you add later, and keeps it current with no further steps. Linking a folder works on **every plan**. It doesn't use up an **[integration](/docs/guides/integrations)** slot, and it doesn't need a Google connection: it uses the Google account you sign in to big with. ## Before you start * **Sign in to big with Google.** big checks that the folder was shared by the Google account you signed in with, so nobody can link a folder they don't control. * **You need to be a workspace admin or the owner** to link or unlink a folder. Everyone in the workspace can see the linked folders and their documents. ## Link a folder Open **Connect → Integrations → Google Drive**. The page shows big's address. It ends in `iam.gserviceaccount.com`: it is big's own reading account, not a person. 1. Choose **Copy** beside big's address. 2. In Google Drive, right-click the folder you want big to use and choose **Share**. 3. Add big's address as a **Viewer**, untick **Notify people**, then choose **Share**. 4. Back in big, paste the folder's link (from **Share → Copy link**, or the address bar while the folder is open) and choose **Link folder**. big checks that the folder is shared with it and that you shared it, then starts reading. Google can take a moment to tell big about a new share, so big keeps checking for about two minutes; if it still can't see the folder, choose **Check again**. Sharing a folder gives big everything in it, sub-folders included. A folder shared with big's address that nobody has linked in big is ignored: big reads nothing from it. **Work or school accounts.** If Drive refuses to share outside your organisation, your Google admin needs to allow sharing with big's address, usually by adding the `iam.gserviceaccount.com` domain it ends in to the allowed external domains. A personal Gmail account needs nothing extra. **big only reads, even as Editor.** If you share the folder as Editor by mistake, big warns you, and still never changes anything. Change the share to Viewer in Drive to be safe. ## What big reads | In the folder | What big keeps | | ----------------------------------------------- | --------------------------------------------------------------------------- | | A Google Doc or Google Slides deck | Its title, where it sits in the folder, when it last changed, and its text. | | A Google Sheet | The same, with the text of its **first sheet** only. | | Any other file (PDF, Word, images and the rest) | Its title, type and when it last changed. Not its contents. | | A shortcut to a file somewhere else | Nothing. big never follows a shortcut out of the folder. | big also keeps the folder names, and the email address of the Google account that shared the folder, as part of the link. A Google file whose text is over 10 MB, or whose owner has turned off downloading, printing and copying for viewers, is kept by title only. If Google can't hand over a file's text for a while, big keeps its title and tries again later, waiting longer each time, up to a day. ## How quickly changes arrive * **The first copy.** Titles of about a thousand files are listed within about ten minutes. Text takes longer, because big fetches it a few files at a time. * **Changes.** big checks Google for changes every few minutes, and most new and edited files arrive at that pace. * **Every change, within a day.** Some changes are only guaranteed by big's full re-check of each folder, which runs once a day: changes deep inside sub-folders, folders in a shared drive, and a file moved out of the folder. Your folder is the source, and big follows it. A file you add, edit or move into the folder is read again. A file you delete, trash or move out of the folder is deleted from big with its text, within one sync. A sub-folder you remove is deleted from big with everything in it. ## Limits on each plan | Plan | Linked folders | Synced files | Synced text and files | | ---------------- | -------------- | ------------ | --------------------- | | **teeny** (free) | 1 | 200 | 100 MB | | **tiny** | 3 | 2,000 | 1 GB | | **big** | 10 | 10,000 | 5 GB | | **bigger** | 25 | 50,000 | 20 GB | * **Files and storage count across every linked folder** in the workspace. A single folder also holds at most 5,000 files and 1,000 sub-folders in big, on every plan. * **Synced copies don't use your [Files](/docs/guides/files) storage.** The Files page shows them on a separate line. * **Past a limit, big keeps what it holds current** and stops adding new files. The folder says on the Google Drive page that your plan's file limit is reached, with a link to upgrade. * **Downgrading deletes nothing.** Folders you already linked keep syncing; you can't link a new folder, and new files aren't added, until you are back under the new plan's limits. ## Where you see your documents The **Google Drive** page lists each linked folder with its state (**Syncing** with a file count, **Synced** with the last sync time, or **Access lost**, plus a notice when your plan's file limit is reached) and, below, the synced documents. Search them by title and text, and open any of them with **Open in Drive**. ### AI agents On every plan except teeny, an AI tool you connect to big's **[MCP server](/docs/developers/mcp)**, or a script using the **[CLI](/docs/developers/cli/command-reference#client-records)**, can read the synced documents, **read-only**: * search or list them with `list_documents` (`big documents list --search ""` on the CLI), each with the folder it sits in; * read one document's text, a page at a time, with `get_document` (`big documents get `); * see the linked folders, how far each has got and big's address with `list_document_folders` (`big documents folders`), which needs `integrations:read`. Linking and unlinking a folder are **dashboard-only**: no token can add a folder to big. Titles, text and folder names are marked as untrusted text, so the AI tool treats them as information, never as instructions. **Every read of a document's text is recorded** in your workspace's audit history: who read which document, through which token, and how much text, never the text itself. big does not use your documents to train AI models. ## Unlink a folder and remove big's access 1. On the **Google Drive** page, choose **Unlink** beside the folder and confirm. big stops reading it at once and deletes every document it synced from that folder. 2. In Google Drive, open the folder's **Share** settings and **remove big's address**. big can't unshare itself, so until you do, the folder stays shared with big's address, though big reads nothing from a folder that isn't linked. You can also do it the other way round: removing big's address in Drive, or deleting or trashing the folder, makes big delete everything it holds from that folder, within about a day. Deleting your big account deletes every synced document too. ## What big never does * **big never changes anything in your Drive.** It only reads: it never edits, moves, renames, shares or deletes a file or folder, whatever role you share it with. * **big never unshares.** Only you can remove big's address from a folder. * **big never sees what you haven't linked.** The rest of your Drive is invisible to it. ## Troubleshooting | What big says | What it means and what to do | | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **big can't link that folder from your Google account** | big checks four things, and answers with this one message whichever fails, so the page never reveals what big can see in Drive: that big can see the folder, that it is a folder and not a file, that it is not in the trash, and that it was shared with big by the Google account you sign in to big with. Share the folder itself, not a file in it, with big's exact address from that account. The page keeps checking for two minutes; then choose **Check again**. If someone else shared it, ask them to link it from their own big sign-in. If it still fails, [contact us](/contact). | | **Waiting for the share to reach big** | One of the checks above has not passed yet, often because the share takes a minute to reach big. Check that your organisation allows sharing with big's address. | | **Sign out and sign in with Google again** | big confirms you shared the folder by your Google sign-in, and yours is more than 7 days old, so big won't trust the email on it. Sign out of big, sign in with Google again, then link the folder. A Google connection with Drive access that you set up yourself in this workspace also counts. | | **Your plan's file limit is reached** | The workspace reached its plan's file or storage limit. Remove files or folders you don't need, or upgrade. See **[Limits on each plan](#limits-on-each-plan)**. | | **Access lost** | big can no longer see the folder: it was unshared, deleted or trashed. big is deleting its copy. Share it again and link it again to start over. | If something here doesn't match what you see, [contact us](/contact). --- # Integrations > Source: https://itsjustbig.com/docs/guides/integrations · Last modified: 2026-10-09T00:00:00.000Z An **integration** connects one of your other tools, such as Calendly or Discord, to your big workspace. A workspace admin connects it once, either by pasting an API key from that tool or by signing in to it and approving big's read-only access. big checks it works and stores the credential encrypted, and from then on big can talk to that tool on the workspace's behalf. The idea is simple: **point your tools at big, and your own AI agent gets the context through big's MCP.** Instead of wiring Claude, Cursor or whichever agent you use to five different vendors, each with its own key sitting in the agent's config, you connect the agent to big once and big holds the credentials. ## What works today This is the first release of integrations, and it is deliberately the foundation: * **Connect, test, re-verify and disconnect** an integration in the dashboard, under **Connect → Integrations**, and rotate a pasted key or reconnect a sign-in. See **[Connect an integration](/docs/guides/integrations/connect)**. * **Two tools so far**: **[Calendly](/docs/guides/integrations/calendly)** and **[Discord](/docs/guides/integrations/discord)** connect with an API key or bot token; their pages say how to create the narrowest credential each allows. **[Google Drive](/docs/guides/integrations/google-drive)** folders link by sharing, with no credential at all, and don't count toward the limit below. * **Your agent can see what is connected.** The read-only `integration_status` tool on big's **[MCP servers](/docs/developers/mcp)**, `big integrations list` on the **[CLI](/docs/developers/cli/command-reference#integrations)** and `GET /api/integrations/status` on the **[API](/docs/developers/api-reference#integrations)** report each integration's provider, status, and when it was last checked and used, and, for an integration whose parts are turned on one at a time, which parts are on. Where a workspace has a meeting integration that imports past calls, an admin's agent can also start, follow and cancel that import. * **Your agent can read what connected tools brought into client records.** With the `clients:read` scope, it can read, read-only, the call transcripts and calendar events an integration your workspace has been set up for imported into **[client records](/docs/client-records)**, and the documents a file store keeps for the workspace. Every document read is recorded in your workspace's audit history, without the document's text. **Asking a connected tool a live question through big's MCP comes next.** Today your agent can see which tools are connected and healthy, and read what they imported into client records; it cannot yet ask big for your upcoming Calendly bookings. When that arrives, it will be curated, read-only questions per tool, never an open line to the tool's whole API. ## Plan limits How many integrations a workspace can connect depends on its plan: | Plan | Integrations | | ---------------- | ------------ | | **teeny** (free) | 2 | | **tiny** | 5 | | **big** | 15 | | **bigger** | 50 | This is **separate from your Instagram and Facebook account limit**. Connecting Calendly never uses up a messaging slot, and connecting another Instagram account never uses up an integration. Every tool is available on every plan. Moving to a smaller plan never disconnects anything; see **[If you downgrade](/docs/guides/integrations/connect#if-you-downgrade)**. The full plan comparison is on **[Plans](/docs/guides/account/plans#integration-limits)**. ## Who can do what | Who | Can | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Admins and the owner** | Connect, reconnect, rotate, re-verify and disconnect, in the dashboard only. Start and cancel an import of past calls from a meeting integration, in the dashboard, the CLI or MCP. | | **Editors and viewers** | See every integration and its status, the connected account, a pasted key's last 4 characters and fingerprint, and when it was last checked. The admin controls don't appear for them. | | **API tokens, the CLI and MCP** | Read status, with the `integrations:read` scope. An admin's token with `meeting-sync:write` can also start and cancel an import of past calls from a meeting integration. Nothing else. | | **Anyone, including big staff** | Read a saved key or sign-in token back: **nobody can.** No screen, API, CLI command or MCP tool returns one. | Connecting, reconnecting, rotating and disconnecting are dashboard-only on purpose. Those actions handle a live credential: a key typed into a CLI flag or an agent's chat would end up in shell history and transcripts, and signing in to a tool needs a browser. See **[Integration security](/docs/guides/integrations/security)** for how credentials are stored and deleted. An integration belongs to the **workspace**, not to the admin who connected it, so demoting or removing that admin doesn't disconnect it. See **[Team & roles](/docs/guides/account/team)**. --- # Integration security > Source: https://itsjustbig.com/docs/guides/integrations/security · Last modified: 2026-10-09T00:00:00.000Z An API key for one of your tools is a password to that tool's account, and so is the sign-in token a tool gives big when you approve it. This page is what big does with them. Tools connect in one of two ways, and big stores each differently: * **A pasted API key**: **[Calendly](/docs/guides/integrations/calendly)** and **[Discord](/docs/guides/integrations/discord)**. * **A sign-in token** (OAuth) that the tool issues when you approve big's read-only access, for the few integrations big sets up for specific workspaces. There is no key to paste. ## What big stores When an admin connects an integration, big stores: * **The credential itself, encrypted**: the API key, or the sign-in tokens (a short-lived access token and the refresh token big uses to renew it). More on how below. * **Which tool it's for, and the label** the admin gave it. * **The account it belongs to** on the tool's side (its account id and its account name or label), as the tool reported it when big checked it. * **For a pasted key only: the last 4 characters and a fingerprint**, so you can tell keys apart without seeing them. A key shorter than 20 characters gets no last 4, since 4 characters would give away too much of it; the fingerprint alone identifies it. Sign-in tokens have neither: you never see them, and they change every time big renews them. * **Dates**: when it was connected, last checked, last used and last rotated, and the code of the last error, if any. For most tools, apart from that account id and name, big doesn't copy any of the tool's data into big in this release; it calls the tool only to check the credential. The tools that feed client records are the exception. An integration your workspace has been set up for imports only what it is for into your client records: from a meeting tool, call transcripts, attendee names and emails, and AI summaries; from a file store, the text of the documents in the folders shared with big, kept for the whole workspace rather than on a client; from a calendar, the times of events your clients attend and which clients are on them. big keeps a raw copy of each transcript file and each file's text in private storage, so a failed import is retried from big's copy rather than from the tool. What happens to that data when you disconnect is under **[Disconnect deletes the credential](#disconnect-deletes-the-credential)**. ## How a pasted key is encrypted Every pasted key is encrypted twice over, in layers: 1. **Each connection gets its own encryption key**, generated fresh when you connect or rotate, and the API key is encrypted with it (AES-256-GCM). 2. **That per-connection key is then encrypted ("wrapped") by a master key held in Google Cloud KMS**, on hardware security modules. The master key never leaves Google's hardware, and it rotates automatically every 90 days. To wrap and unwrap it, Google Cloud KMS receives the per-connection key, together with internal ids (the workspace, the integration and the provider) as authenticated data that ties the wrapped key to this one connection. **Google never receives your API key or its encrypted form**, or any other content from your workspace, so Google Cloud alone can't decrypt a key, and neither can big's database alone. The same envelope protects sign-in refresh tokens, below. That makes Google Cloud a sub-processor for this one purpose; see **[Your data](/docs/guides/account/your-data#integration-keys-you-give-big)**. Each encrypted key is also bound to its workspace, its connection and its current version, so an encrypted key copied into another workspace, or restored from before a rotation, can't be decrypted. Only big's production service can ask Google Cloud to unwrap a key, every unwrap is logged by Google, and no person at big, engineers included, holds the permission to unwrap one. ## How sign-in tokens are encrypted A sign-in gives big two tokens, and each is protected the way its job needs: * **The refresh token**, the long-lived one big uses to get new access, is encrypted the same way as a pasted key: with its own freshly generated encryption key (AES-256-GCM), which is wrapped by the master key held in Google Cloud KMS. Google Cloud KMS receives that per-token key and the internal ids that bind it to this one connection, **never the refresh token or its encrypted form**. Refresh tokens saved before October 2026 were encrypted with big's own token key; each moves to this form the next time big renews it. Until then big reads both forms. * **The short-lived access token** is encrypted with big's own token key (AES-256-GCM), the same one that protects your connected Instagram and Facebook accounts' access, so a call to the tool never waits on Google Cloud. That key lives only in big's production environment, never in the database. * **Each token is bound to its place.** The encryption ties every token to its integration, its workspace and the current version of the connection. A token copied to another integration or workspace, or into the wrong column, can't be decrypted. * **Tokens live in their own table** that big's application code can't read directly. Only a handful of database functions can reach it, each one checks the workspace, and big's code that reads the rest of your workspace can't see it at all. * **While you are on the confirm screen**, the tokens the tool just issued wait in the same kind of isolated table, bound to the tool, your workspace, the admin who started, and that one attempt. Cancelling or letting the screen expire deletes them. * **A sign-in uses PKCE where the tool supports it.** The one-time proof that the sign-in really started in big is encrypted the same way and deleted as soon as it is used. **Renewing.** Access tokens are short-lived. big renews one with the refresh token shortly before it runs out, and stores the new pair in place of the old. Where a tool lets you approve its permissions one at a time, big also checks on every renewal that the access it needs is still there; access that has shrunk below that, or grown beyond what big asked for, is refused, and the integration moves to **Reconnect needed**. If the tool refuses to renew because big's access was revoked or the app removed, the integration moves to **Reconnect needed** and your admins are told; see **[Reconnect](/docs/guides/integrations/connect#reconnect)**. A fault on big's side, such as a token that can't be decrypted, is never treated as a revoked grant: it doesn't delete anything or ask you to reconnect. ## What you can see Once saved, a credential is **never shown again**. The dashboard, the CLI, the API and both MCP servers show only: * **For a pasted key, the last 4 characters**, to recognise it at a glance. Keys shorter than 20 characters show none. * **For a pasted key, a fingerprint**, a short code computed from the key with a secret only big holds. The same key always gives the same fingerprint, so you can check "is this the key we rotated from?" without either key being shown. Because it needs big's secret, a fingerprint can't be used to test guessed or stolen keys. * **For a tool you signed in to, the account** big is connected to. **Nobody can read a key or token back after saving**: not you, not your admins, and not big staff, whatever their access. There is no reveal button and no endpoint that returns one. When you need a key again, create a new one in the tool and rotate. ## Writes are dashboard-only Connecting, reconnecting, rotating, re-verifying and disconnecting work **only in the dashboard**, signed in as an admin. * **API tokens and MCP can never read or change credentials.** The `integrations:read` scope lets a token read the status fields above and nothing else. There is no `integrations:write` scope to grant. A token that tries one of the write actions is refused with a message saying it is dashboard-only, and the attempt is recorded in your workspace's audit history. * **Why:** a key typed into a CLI command or an agent's chat would land in shell history and chat transcripts, a leaked API token should never be enough to swap in someone else's credential or pull yours out, and signing in to a tool needs a browser anyway. * **Signing in is bound to the admin who started it.** big only accepts the tool's answer in the same browser, from the same signed-in admin, within 15 minutes, and saves nothing until that admin confirms. A link someone sends you can't attach their account to your workspace. Every connect, reconnect, rotate, disconnect and failed check is recorded in the workspace's audit history, with a key's fingerprint and never the key or a token. ## Calls to your tools * **Only the tool's official API address.** Each tool's address is fixed inside big. No field you fill in can point big somewhere else, and big refuses to follow a redirect with your credential attached. * **Sign-in tokens are renewed only at the tool's fixed address.** big asks for a new access token only at the tool's own sign-in address, and never logs a token. * **The tool's own error text is never shown or logged.** When a check fails you get a short, fixed explanation from big, because a tool's error response can echo the credential back. * **Credentials are kept out of logs.** big scrubs anything shaped like a key from its logs, and never logs a key, a token, their encrypted form or the tool's response body. ## Disconnect deletes the credential **Disconnecting deletes the stored key or tokens from big's live database immediately**, together with a key's per-connection encryption key. What remains is the small audit record (tool, label, account, dates, a key's fingerprint), kept with your workspace's audit history and deleted with the workspace. Deleting the workspace deletes every integration's credential the same way. Whether the tool forgets big too depends on the tool: * **An API key: big can't revoke it.** API keys are revoked where they were issued, so after you disconnect or rotate, delete the old key in the tool itself. * **A tool you signed in to: revoked where the tool allows.** Disconnect asks the tool to revoke big's access first, then deletes big's copy whether or not the tool answered. Where a tool has no revoke, remove big from your authorized apps in the tool. * **A meeting integration: the imported calls are deleted.** Disconnecting a meeting integration your workspace has been set up for also deletes every call big imported only from it, with its transcript, attendees and summary, big's raw copies of the transcript files, and any import of past calls still running. Recordings in the tool are never touched, and deleting a recording there does not delete big's copy. * **A calendar integration: the update feeds are stopped first, then everything it imported is deleted.** Disconnecting one your workspace has been set up for first tells the tool to stop sending big updates, using big's access while it still works, then asks the tool to revoke that access, and then deletes every calendar event big kept from it. Your calendar in the tool is never touched. * **A file store: unlink the folder.** big reads only the folders you link and share with it, and deletes a document's copy and text once it leaves a linked folder, or every document of a folder once you unlink it or it stops being shared with big. big can't unshare itself, so also remove its address from the folder in the tool. See **[Google Drive](/docs/guides/integrations/google-drive)**. Your files in the tool are never touched. ## Backups big's database backups let us restore the database to a point in the past, for a limited window: `NEON_PITR_DAYS` days. A key or token you disconnected therefore still exists, encrypted, inside those backups until that window has passed, and only big's production service holds what it takes to decrypt it. After the window, it is gone from backups too. Deleting big's copy doesn't stop a credential working at the tool. A key you pasted keeps working until you delete it in the tool. Revoke it at the tool to invalidate it. ## Least privilege The safest credential is one that can't do much: * **[Calendly](/docs/guides/integrations/calendly)**: a personal access token. Calendly doesn't offer scoped tokens. * **[Discord](/docs/guides/integrations/discord)**: a bot token for a bot you create, with only the permissions big needs. --- # Blocks > Source: https://itsjustbig.com/docs/guides/trees/blocks · Last modified: 2026-09-21T00:00:00.000Z Everything on a link page is a **block**. You add, reorder, hide, and delete blocks in the editor's **Build** tab, then save. ## The five block types | Block | What it renders | What it needs | | ----------- | ----------------------------- | -------------------------------------------------------------------------------------------------------------------- | | **Link** | A tracked button to any URL | A title and an absolute `http://` or `https://` URL. Optionally a thumbnail image from Files. | | **Form** | A button to one of your forms | One of your workspace's forms, plus the button label. | | **Socials** | A row of profile chips | 1–10 entries, each a network (Instagram, X, TikTok, YouTube, Threads, or Website) and an `http(s)` URL. | | **Image** | An image from your Files | A ready image asset, plus alt text (up to 200 characters; may be left empty). Optionally a link to open when tapped. | | **Header** | A small section label | Text (1–100 characters). | Block titles and labels are capped at 100 characters. A **form** block sends people from this page to one of your forms. The return trip exists too: that form's post-submit screen can offer a button back to one of your link pages — see **[The confirmation screen](/docs/guides/forms#the-confirmation-screen)**. ## Hiding a block Every block carries a **visible** flag. Hiding a block keeps it in the page definition and in the editor but stops it rendering publicly — use it to park something you'll bring back rather than deleting and rebuilding it. Hidden blocks are also left out of **[stats](/docs/guides/trees/stats)**, because they can't have been seen. ## Link blocks mint a short link When you save a link block for the first time, big creates a **[short link](/docs/guides/links)** for it and the public page renders that short link, not your target URL. That's what makes per-block click counts possible. Two consequences worth knowing: * **Editing a link block's URL retargets the same code.** The click history stays attached, so your numbers don't reset when you fix a typo or swap a campaign destination. * **Those short links are the page's, not entries in your links list.** They're left out of **Links → Short links** (and `big links` / `GET /api/links`) by default, since you never typed those codes — read their clicks on the page's **[Stats](/docs/guides/trees/stats)** tab instead. To list them anyway, see **[Links created for you](/docs/guides/links#links-created-for-you)**. ## Linking to OnlyFans or Fansly age-checks the page A **link button**, the **website** entry in a socials row, or a **tappable image** pointing at `onlyfans.com` or `fansly.com` puts an age check in front of the whole page: visitors confirm they're 18 or older before anything loads. It applies to blocks a visitor can actually reach, so a hidden block doesn't trigger it, and it isn't a setting you can turn on or off — see **[Sensitive content](/docs/guides/trees/sensitive-content)**. ## A missing reference hides the block Blocks store *references* — a form's id, a file's id, a short-link code — not a copy of the thing. When the page is rendered, big re-checks every reference against your workspace. If a reference no longer resolves, that one block is silently left off the page instead of breaking it. This happens when: * the image was deleted from Files, hasn't finished processing, or isn't a previewable image format; * the form was deleted, or is no longer **active** (a draft or closed form's button disappears rather than dead-ending); * the short link behind a link block was deleted (Links → Short links, **Show them too**). The rest of the page renders normally, and visitors are never told why something is missing. If a block vanishes from your live page, check its reference first. ## Bounds A page holds at most **200 blocks**, and the whole block definition must serialize to under **64 KiB**. These are abuse guards, not plan limits — there is no per-plan cap on link pages. ## Editing safely The editor saves the whole block list at once and refuses a save that would overwrite someone else's newer version — if a teammate (or another browser tab) changed the page since you loaded it, you're told to reload rather than silently clobbering their work. --- # Link pages > Source: https://itsjustbig.com/docs/guides/trees · Last modified: 2026-09-21T00:00:00.000Z > **Link pages** and **[short links](/docs/guides/links)** sit side by side under **Links** in the sidebar: a link page is one hosted page at `itsjustbig.com/t/` holding many buttons, a short link is one redirect at `/l/`. Every link button you add to a link page mints a short link behind the scenes. A link page is a list of **blocks** stacked on one public page. You build it in the dashboard, pick a theme, publish it, and share one URL. ## What a link page is made of | Part | What it is | | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Handle** | The public address: `itsjustbig.com/t/`. Unique across all of big. | | **Profile** | Avatar, display name, and a short bio, shown above the blocks. | | **Blocks** | The stacked content: link buttons, form buttons, a socials row, images, and section headers. See **[Blocks](/docs/guides/trees/blocks)**. | | **Theme** | Background, accent colour, button shape and fill, font, avatar shape. See **[Theme](/docs/guides/trees/theme)**. | | **Status** | `draft` or `published`. Only a published page is reachable. See **[Publish and handles](/docs/guides/trees/publish)**. | | **Age check** | Added automatically when your blocks link to OnlyFans or Fansly — visitors confirm they're 18 or older before the page loads. Not a setting. See **[Sensitive content](/docs/guides/trees/sensitive-content)**. | ## Create one 1. Open **Links** in the sidebar and choose **New link page** (editor role or higher). 2. Enter a **handle** — this claims the address immediately. Typing a display name suggests a handle for you. 3. Optionally enter a **display name**. Both can be changed later. You land in the editor with three tabs: * **Build** — profile fields and the block list. * **Theme** — colours, fonts, button styling, background. * **Stats** — page views and per-block numbers (see **[Link page stats](/docs/guides/trees/stats)**). Build and Theme share one unsaved-changes state, so switching between them keeps your edits; Stats is a real navigation and will prompt you if you have unsaved work. ## Profile fields * **Display name** — up to 100 characters. * **Bio** — up to 300 characters. * **Avatar** — picked from your **[Files](/docs/guides/files)**; it must be an uploaded image that finished processing. ## Link pages and forms point at each other Both directions exist, and together they close a loop: * **A link page → a form.** Add a **form block** and the page renders a button to one of your workspace's forms. See **[Blocks](/docs/guides/trees/blocks)**. * **A form → a link page.** A form's post-submit screen can offer a button to one of your link pages, so someone who has just submitted lands on everything else you're sharing rather than on a dead "Thanks!". See **[The confirmation screen](/docs/guides/forms#the-confirmation-screen)**. The second direction is what lets one link in your Instagram bio do two jobs: it points at the form, so the visit becomes a lead, and the thank-you hands that person your page. ## Limits There is no plan cap on link pages, blocks, or views — every plan gets the same. Two technical bounds exist purely to keep a page sane: a maximum of **200 blocks**, and the whole block definition must serialize to under **64 KiB**. Neither is reachable by building a page by hand. A workspace also keeps at most **100 link pages**, flat on every plan, which in practice only shows up when pages are being created from a script. ## Building a page outside the dashboard Link pages have a programmatic surface: the **[API](/docs/developers/api-reference#link-pages)** (scopes `link-pages:read` and `link-pages:write`), the **[CLI](/docs/developers/cli/command-reference#link-pages)** (`big link-pages`, `big link-page:view` / `:create` / `:edit` / `:publish` / `:revisions` / `:restore`), and both **[MCP servers](/docs/developers/mcp)** for listing, reading, creating, and asking to publish. **It goes as far as asking, and a person finishes it.** You can list your pages, read one in full, create one, edit one *while it is a draft*, read its version history, and restore an old version into the draft. **Publishing and unpublishing are reachable too** — but a publish asked for by a token, a command or an agent doesn't happen until someone approves it in the browser, at the page's own approve screen. See **[Approving a publish](/docs/guides/trees/publish#approving-a-publish-an-agent-or-the-cli-asked-for)**. Two things stay dashboard-only, on purpose rather than pending: | Dashboard-only | Why | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Renaming the handle** | A rename releases the old handle immediately, with no redirect — see **[Renaming a handle](/docs/guides/trees/publish#renaming-a-handle)**. A script watching for renames could claim it the same second. | | **Deleting a page** | It takes the page's whole view history with it, and there's no undo. | **Editing a page that's already published is still refused** as well. Your audience already has that URL, and a one-shot overwrite of a live page isn't the same act as editing a draft — unpublish it, or edit the draft and publish that. Three more things worth knowing before you point a script at a page. A write has to carry the `updatedAt` you read, so an edit that raced a person editing in the dashboard fails instead of quietly overwriting them. A saved block can't be repointed at a new URL once it has minted its short link — that `/l/` code may already be in a bio or a printed QR code — so remove the block and add it back, which mints a fresh one. And creating a page over a token is refused once the workspace holds 100 of them, with a warning from 70 that names the pages nothing has visited lately. All three are explained in **[Link pages](/docs/developers/api-reference#link-pages)**. Editing exists on the CLI and the API but **not** on either MCP server: a page's blocks are replaced wholesale, and that is a bigger thing to hand a model reading DMs than a person typing a command. See **[Editing a link page is CLI-only](/docs/developers/mcp#editing-a-link-page-is-cli-only)**. ## What's not there yet * **No custom domains.** Every page lives under `itsjustbig.com/t/`. * **No per-block scheduling or expiry.** A block is either visible or hidden. ## Where to go next * **[Blocks](/docs/guides/trees/blocks)** — the five block types and what each needs. * **[Theme](/docs/guides/trees/theme)** — every styling option. * **[Publish and handles](/docs/guides/trees/publish)** — going live, renaming, reserved words. * **[Sensitive content](/docs/guides/trees/sensitive-content)** — when visitors are asked to confirm their age first. * **[Link page stats](/docs/guides/trees/stats)** — views, clicks per block, form views. --- # Publish and handles > Source: https://itsjustbig.com/docs/guides/trees/publish · Last modified: 2026-10-02T00:00:00.000Z A link page has two states: **draft** and **published**. Only a published page is reachable by anyone but you. A published page can also have a **draft of its own** — a working copy of the page that nobody outside your workspace can see. When that's the case the live page and the draft are two different documents, and the rest of this page is mostly about the gap between them. ## Your handle The handle is the page's public address: `itsjustbig.com/t/`. * **Claimed at creation.** You pick it when you create the page, before you've built anything, so the address is yours while you work. * **Globally unique.** Handles are unique across all of big, not just your workspace — if it's taken, you're told before you submit. * **3–30 characters**, lowercase letters, digits, and `.`, `-`, `_`. It must start and end with a letter or digit, and can't contain two separators in a row (`my..page` and `my-.page` are rejected). Uppercase input is lowercased for you rather than refused. * **Reserved words can't be claimed.** Roughly ninety terms are held back: big's own routes (`docs`, `login`, `settings`, `forms`, `inbox`, …), brand and product words (`big`, `links`, `bio`), and trust terms people use for impersonation (`official`, `verify`, `support`, `billing`, `security`, `instagram`, …). You'll get a "that handle is reserved" message, distinct from "that handle is taken". ## Publishing Publish from the editor. Until you do, the page's content never leaves big — a draft isn't just hidden behind a check, it's excluded from the public lookup entirely. An unknown handle, a draft page, a reserved word, and a temporary lookup failure all return the **same 404**. A visitor can't use the public page to work out whether a handle exists as a draft. ## Unpublished changes Once a page has a draft, the editor shows an **Unpublished changes** panel above the action bar. It tells you when the draft was last saved and summarises what would change if it went live: > 2 blocks added · 1 block edited · Blocks reordered · Theme changed · Bio is now "Everything I make, in one place." It's a summary, not a preview — counts and field names, never the block contents. That's deliberate: if a draft was written by an agent, the one place you shouldn't be reading whatever it typed is the screen where you decide to make it public. Two things follow from a draft existing: * **Visitors still see the published version.** Nothing in the draft is on your `/t/` URL, and nothing gets there by waiting. That includes the short links behind your buttons: changing a link's URL in the draft doesn't change where its `/l/` link sends people until the draft is published. * **Nothing in it goes live until a publish covers that exact draft.** A publish names the draft it read, so a change made after you looked at it isn't carried along quietly. If the page has never been published, the same panel says so instead: nobody can see it yet, and these are the changes that will go live the first time you publish. ## Version history Every publish leaves a **version** behind — a frozen copy of exactly what went live, in the editor's version history, newest first. Each row says when it went live and where it came from: from the dashboard, from an API token, or from an agent. **Restore** copies a version back into your draft. It never changes the live page on its own — that's the point of it. A restored version sits in the draft like any other unpublished work, you can edit it further, and it goes live only when a publish does. Restoring **overwrites whatever is in the draft**, including edits an agent may have made minutes ago, so the confirmation says so before it happens. **History keeps the last 10 versions of a page.** From the 7th, the editor starts telling you how many publishes are left before the oldest one rolls off. When the 11th version is published, the oldest is deleted to make room. That roll-off never blocks anything. Publishing is the one action that always has to work — a page that couldn't go live because its *history* was full would be a storage limit causing an outage — so the old version goes rather than the publish. The warning from 7 is what gives you three publishes of notice while the version you might want is still there. If there's an old version you want to keep, restore it into the draft before it rolls off. ## Approving a publish an agent or the CLI asked for Publishing is no longer dashboard-only. The **[CLI](/docs/developers/cli/command-reference#publishing-and-the-version-history)**, the **[API](/docs/developers/api-reference#publishing-needs-a-person)** and an AI agent connected to your workspace can all ask to publish a page — but none of them can finish the job. **A person has to approve it in the browser, every time.** How it goes: 1. The tool asks to publish and gets a short code back — something like `BRZK-4QT2` — printed in the terminal or handed to you by the agent. 2. You open the page in big and go to **Review and approve a publish** (the link is in the Unpublished changes panel, at `/links//approve`). 3. The screen shows you the same summary of what would go live, read from the page itself rather than from anything the tool told us. 4. You enter the code. The publish goes through, and not before. A few things worth knowing: * **The code expires after 10 minutes and works once.** If it's gone stale, ask for the publish again and you'll get a fresh one. * **Only an owner or admin can approve.** Editors can build and edit the page, but the person consenting to put it on a public URL is an admin. * **The approval is bound to the draft it was asked for.** If the draft changes after you approve — an agent edits it again in the gap — the approval no longer matches and the publish is refused rather than shipping something you never read. It is bound to this page, too: a code an agent got for a different page, or for a form, approves nothing when typed here — you see the same "not usable" message as for a wrong code. Forms have their own screen at `/forms//approve`. * **Approve only a code you can see yourself**, on a terminal you're looking at or from an agent you just asked. A code someone sends you is not a reason to approve anything. * **Unpublishing needs no code.** Taking a page down is the thing you do when something went wrong, so it's never harder than putting it up. Publishing from the dashboard needs no code either — you're already the person the code exists to find. ## What big. adds to your page Two things appear on every published link page, below whatever you built: * **The "made with big." badge**, pinned to the bottom of the screen while the visitor scrolls. It's on every page on every plan, and there's no way to remove it. * **A footer row** — About · Report · Terms · Privacy. **About** explains what big. is to a visitor who's never heard of us, **Report** lets anyone flag a page that breaks the [terms](/terms), and the last two open big's legal pages in a new tab. Neither is themed: they stay a dark panel whatever background and colours you pick, so they read as big's rather than yours. Nothing in either one collects a visitor's details or interrupts your page — the footer row is quiet type below your last block, and About and Report only open when tapped. A third thing appears on **some** pages: an **age check** in front of the whole page, if your blocks link to OnlyFans or Fansly. It isn't something you switch on, and it replaces the page rather than sitting on it — see **[Sensitive content](/docs/guides/trees/sensitive-content)**. **Anyone can report your page**, including people who don't have a big. account. Reports go to us, not to you, and we don't tell the reporter who you are. If a page breaks the terms we may remove content or suspend the account behind it — see [Report a page](/report) for what we act on. ## Unpublishing Unpublishing returns the page to **draft**. The URL immediately 404s again, and the handle stays yours. The short links your link blocks minted are **not** deleted when you unpublish — they keep redirecting, and their click history is intact. Your version history isn't touched either: unpublishing changes where the page is reachable, not what it says. ## Renaming a handle You can change the handle later. The new one goes through the same format and reserved-word checks. Be deliberate about it: the old address stops working the moment the rename lands, there's no redirect from it, and it becomes claimable by someone else. Anything already printed or posted with the old handle breaks. Renaming stays a dashboard action — no token, CLI command, or agent can do it. A rename releases the old handle the same second, and a script watching for one could claim it before you'd finished typing. ## Deleting a link page Deleting the page does **not** delete the short links it minted. Their codes keep redirecting and their click history survives — they're simply flagged as no longer belonging to a page. Since nothing owns them any more, they don't appear in **Links → Short links** by default: click **Show them too** above the list to find them, and delete them there if you want the redirects gone as well. See **[Links created for you](/docs/guides/links#links-created-for-you)**. Deleting is dashboard-only too, for the same kind of reason: it takes the page's whole view history with it, and there's no undo. --- # Sensitive content > Source: https://itsjustbig.com/docs/guides/trees/sensitive-content · Last modified: 2026-09-21T00:00:00.000Z If a link page sends visitors to an **adult subscription platform**, big. shows an age check before the page itself. The visitor sees a plain screen — *Sensitive content*, one sentence, and two buttons — and your page loads once they confirm they're of legal age. You don't turn this on. It follows from your links. It applies to **short links too** — see [Short links are checked as well](#short-links-are-checked-as-well) below. ## What triggers it A page is age-checked when anything on it that **a visitor can actually tap** leads to: * **OnlyFans** (`onlyfans.com`, and any subdomain) * **Fansly** (`fansly.com`, and any subdomain) That covers all three places a destination can live: a **link button**, the **website** entry in a socials row, and an **image block** you've made tappable. Some things deliberately don't trigger it: | Not triggered by | Why | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | A **hidden** block | Nobody can reach it, so there's nothing to check an age for. | | A link block that isn't rendering | Same reason — if the button isn't on the page, its destination doesn't count. | | Another site that *mentions* those platforms | Only the destination host is read. A blog post about OnlyFans hosted somewhere else is an ordinary link. | | A domain that merely contains the name | `notonlyfans.com` is a different site and is treated as one. | | Someone **else's** link shortener | A `bit.ly` link, your own domain, or another link-in-bio service is opaque to us — see [What it can't see](#what-it-cant-see). | | Your **bio text** or a **header block** | Neither carries a destination. | **Shortening the link first doesn't avoid it.** If you point a button at one of your own big short links, we follow that link to see where it lands. `itsjustbig.com/l/abc` → `onlyfans.com` age-checks the page exactly as the direct link would, and so does a chain of your own short links, up to three deep. A **[tagged link](/docs/guides/links/attribution)** counts as the link it was copied from, so pasting the one you copied for a channel behaves the same way. ## What the visitor sees The age check replaces your page. It doesn't sit on top of it, and it isn't a banner you can scroll past: your avatar and your blocks aren't sent to the browser at all until someone confirms. The **share card** is the deliberate exception. When your page is posted somewhere that unfurls a preview, that preview still carries your name and bio — a link that says whose page it is, so the person who taps it knows who they're confirming for. * **I am 18 or older** — your page loads, and they aren't asked again on *your* page while their browser stays open. * **I am under 18** — the page says it can't be shown, with a link back to big. Both answers are **per page** and last **one browsing session**. Confirming on your page doesn't unlock anyone else's — the next age-checked page they open asks again — and closing the browser clears every answer, so a returning visitor is asked afresh. That's the narrow reading on purpose. An answer is about the page in front of someone: confirming for one creator isn't a request to be let into creators they've never heard of. And a longer memory would turn a tap into durable state on a stranger's device — much of this traffic is a phone's in-app browser, sometimes a shared or borrowed one — where a page acknowledged weeks ago would open with no check at all for whoever is holding it now. The check isn't themed. It's big's screen, in big's colours, whatever background and buttons you've picked — the same reasoning behind the footer row in **[What big. adds to your page](/docs/guides/trees/publish#what-big-adds-to-your-page)**. Nothing about the answer is stored on our side: no account, no contact record, no entry in your stats. It's one cookie in the visitor's own browser. ## What it does to your numbers **Page views only count visitors who got through the check.** Somebody who lands on the age screen and leaves isn't a view of your page, because they never saw it — see **[Page views](/docs/guides/trees/stats#page-views)**. Clicks on your blocks are unaffected: they're counted at the `/l/` redirect, and only somebody looking at your page can tap one. ## Where it shows up while you're editing The editor tells you, under the phone preview: *Visitors confirm they are 18 or older before this page opens.* The preview itself stays ungated — it's your page, and you shouldn't have to tap through an age check to reach your own blocks. Outside the dashboard, a page reports it as `sensitiveContent` — on the API, on both MCP servers, and in `big link-page:view`. It's read-only everywhere: there's no field to set and no override, because the links are the setting. **`sensitiveContent: false` is the weaker answer, and so is a silent editor.** Both read the link targets on the block itself; neither follows one of your own `/l` short links the way the live page does. So a page whose only adult destination sits behind a short link you made reports `false`, shows no banner under the preview — and is still age-checked when a visitor opens it. `true` is authoritative; `false` means "no adult host on a block", never "no age check". ## Turning it off Remove or repoint the links that trigger it. There's no toggle, and that's deliberate: a switch would be a second answer to the question that could disagree with your actual links — and the disagreement that matters is a page marked safe that isn't. ## Short links are checked as well A `/l/` short link that lands on OnlyFans or Fansly shows the same check before it redirects — whether you made it yourself under **Links → Short links**, or it was minted for a link-page button. It applies wherever the link was opened from: a DM, a bio, a QR code, a post caption. Nothing about the click is counted or attributed until the visitor confirms. Campaign tags survive the detour, so a confirmed click is attributed exactly as it would have been. **A page and its own buttons count as one check.** Confirm on someone's link page and their buttons open without asking again; confirm on one of their buttons and their page opens the same way. A standalone short link — one that isn't a page's button — is its own check. ## What it can't see The check reads the **destination**. That is knowable when the link points at the platform, and when it points at one of **our** short links, which we can follow. It is **not** knowable when the link points somewhere else that redirects: a `bit.ly` link, your own domain, another link-in-bio service. We don't fetch those to find out — making our servers follow arbitrary links that anyone can type is its own risk, and it wouldn't settle the question anyway, since anything we could follow could be hidden one hop further along. So the honest statement is narrow: **big's own shortener can't be used to get around the check.** Deliberately routing around it with a third-party redirector is possible, and it's a [terms](/terms) problem rather than a technical one — pages and links that break the terms get [reported](/report) and acted on. --- # Link page stats > Source: https://itsjustbig.com/docs/guides/trees/stats · Last modified: 2026-09-21T00:00:00.000Z Open a link page and choose the **Stats** tab. Three readings sit there, all live. ## Page views The headline number: how many times the public page was loaded, with a unique count and a this-week-versus-last-week comparison. Views are recorded the same way form views and link clicks are — cookieless, with the visitor's IP hashed rather than stored, and obvious bot traffic filtered out. Only a **published** page counts views; drafts, 404s, and the editor's own preview never do. If your page shows an **[age check](/docs/guides/trees/sensitive-content)**, only visitors who got through it are counted. Somebody who met the check and left never saw your page, so counting them would overstate this number rather than fill it in. ## Link blocks Every visible link block that has been saved at least once shows its own click line — total clicks, unique clicks, and the weekly delta — next to the `/l/` it redirects through. A link block that you've just added and not yet saved has no code yet, so it can't have clicks. Hidden blocks are left out entirely. If you've removed link blocks from the page, a footnote counts the short links they left behind. Those codes keep redirecting and keep their history; they're reachable in **Links → Short links** under **Show them too** — see **[Links created for you](/docs/guides/links#links-created-for-you)**. ## Form blocks Each form block shows that **form's** view count, labelled *all sources, not just this page*. That label is literal: it's the same number the form's own stats page shows, counting every visit to the form from anywhere — this page, a DM, a post caption. big can't cheaply split form views by where the visitor came from, so it shows an honest superset rather than a number that looks page-specific and isn't. For the click side of the funnel, use the **link block** numbers above — those *are* page-specific, because each one has its own short link. ## What's not there yet * **No day/month/quarter/year tiers.** Link page stats are weekly (total, unique, this week vs last). Individual short links do have full period breakdowns — see **[Link stats](/docs/guides/links/stats)**. * **No referrer or device breakdown** for page views. * **No CLI or MCP view of this panel.** The per-block breakdown is dashboard-only. A page's *view counts* are readable programmatically — `GET /api/stats/links`, `big stats:links`, and `big_links_stats` / `link_stats`, all under `bioPages` and keyed by page id — and **[`big link-pages`](/docs/developers/cli/command-reference#link-pages)** or `GET /api/trees` maps that id back to a handle. The per-block short links are readable through `big link:stats` and `GET /api/links/:code/stats`. See the **[API reference](/docs/developers/api-reference#stats-and-attribution)**. A hiccup reading any one of the three sections leaves that section empty rather than breaking the page, so an unexpected "no views yet" on a page you know gets traffic is worth a retry before it's worth a support ticket. --- # Theme > Source: https://itsjustbig.com/docs/guides/trees/theme · Last modified: 2026-07-28T00:00:00.000Z The editor's **Theme** tab styles a link page. Every setting is a fixed choice or a colour — there's no CSS to write, and nothing you type reaches the page as code. ## What you can set | Setting | Options | | ---------------- | ---------------------------------------------------------------------- | | **Background** | A solid colour, or an image from your **[Files](/docs/guides/files)**. | | **Accent** | A colour, used for buttons and highlights. | | **Button shape** | `square`, `rounded`, or `pill`. | | **Button fill** | `solid` or `outline`. | | **Font** | `default`, `serif`, `mono`, or `rounded`. | | **Avatar shape** | `circle` or `square`. | Anything you leave unset falls back to the neutral default: rounded solid buttons, the default font, a circular avatar, and no background image. Text colour is derived from your accent automatically so it stays readable — it isn't a setting. ## Presets Three one-click starting points are offered: **neutral** (the out-of-the-box look), **coral**, and **noir**. Picking one just fills in the individual settings — every field stays editable afterwards, and big doesn't remember which preset you started from. ## Background images come from Files You can't paste an image URL. A background image is picked from your **[Files](/docs/guides/files)** library, and the asset has to be an image that finished processing. big serves it through a short-lived signed URL generated per page load. That's deliberate: it keeps a link page from loading anything off a third-party host, and it means deleting the file from Files cleanly drops the background rather than leaving a broken image on your live page. ## Colours Colours are entered as 6-digit hex (`#rrggbb`). Other CSS colour forms — `rgb()`, named colours, gradients, custom properties — aren't accepted.