How AI Agents Can Sign Up Paying Users to Your SaaS

AI agents are getting good at almost everything. They can draft captions, generate images, schedule a week of social posts, and reply to DMs. The one place they still hit a wall is the same place every SaaS product starts: signup.

If your AI agent can only help users who already have an account, you've capped its usefulness at the door. But the obvious workaround is worse than the wall. You do not want an AI agent typing a user's credit card into Stripe, holding their password, or completing an OAuth dance on their behalf. Those are exactly the boundaries that keep agentic software trustworthy.

posterly has had a public REST API and an MCP server for a while. The piece that was missing was a signup flow that an agent could drive without ever touching a credential. We just shipped it. This post walks through what it does, why every part of it is the way it is, and how to wire your agent against it in an afternoon.

Why "just point the agent at the signup page" doesn't work

Most SaaS signup flows are designed for a human in a browser. Walk through what happens when you swap that human for an agent and the cracks show fast:

• Stripe Checkout needs a card. Agents should not be entering card numbers, even when the user volunteers them. The risk surface is too large and the regulatory surface is larger. Stripe Checkout, hosted in the user's browser, is the right place for payment, full stop.
• Provider OAuth needs interactive consent. Connecting an Instagram account means the user has to see Meta's permission screen and explicitly approve scopes. Agents cannot meaningfully consent on behalf of a user, and you do not want a precedent where they try.
• API keys cannot be returned before billing is active. If your agent gets back an API key during signup but the user never finishes checkout, you have a credential floating around with no paid account behind it. Cleanup is messy and security is worse.
• Sessions need to expire. Half-finished flows pile up. Without an expiry, every abandoned signup leaves dangling state for support to chase.

The path forward is a flow with two halves: the agent orchestrates and reports, the user does the things only a human in a browser should do.

The three-endpoint signup flow

The posterly agent signup flow is intentionally small. Three endpoints, one direction.

POST /api/v1/signup
POST /api/v1/connect/{platform}/sessions
GET  /api/v1/connect/sessions/{id}

That's it. Everything else (Stripe Checkout, posterly login, provider OAuth) happens in the user's browser. The agent never sees a token, never sees a password, and never sees a card. The page that documents it lives at poster.ly/agents/signup.

1. Start paid signup

POST https://www.poster.ly/api/v1/signup

The agent calls this with the user's email and basic intent. posterly creates a Stripe Checkout session and returns a checkout_url. The agent hands the URL to the user. The user pays in their own browser. No API key is returned to the agent before billing is active. None.

When checkout completes, posterly creates the first API key in the user's dashboard. The user can hand that key back to the agent themselves, or the agent can fetch it through a paid endpoint once the user is signed in to posterly. Either way, the agent does not see the key during the unauthenticated signup call.

2. Create a connect session

POST https://www.poster.ly/api/v1/connect/{platform}/sessions

Once the user has an API key, the agent can connect social accounts. Calling this endpoint creates a short-lived browser handoff for the chosen platform (Instagram, Meta, YouTube, LinkedIn, X, TikTok, Pinterest, Threads, Google Business Profile, Telegram, Bluesky) and returns two URLs:

• connect_url: where to send the user so they can authorize the account.
• poll_url: where the agent should poll for status.

The session expires after 30 minutes. If the user never finishes, nothing is left lying around.

3. Poll clear progress

GET https://www.poster.ly/api/v1/connect/sessions/{id}

The agent polls this endpoint and reports progress back to the user in plain English. The status field is the entire contract. We'll look at each status next.

What stays in the user's browser. What stays in the agent.

The cleanest way to internalise this flow is to draw a line.

In the user's browser:

• Stripe Checkout (card details, billing address)
• posterly login (email, password or OAuth)
• Provider OAuth screens (Meta, Google, LinkedIn, X, TikTok, etc.)
• Manual credential entry for platforms that don't expose OAuth (Bluesky app passwords, Telegram bot tokens)

In the agent:

• The three API calls above
• Status polling
• Natural-language progress reports to the user
• Whatever your agent does after the user has an API key and connected accounts (scheduling posts, generating images, replying to comments, all of which posterly already supports through 51 MCP tools and the full REST API)

The line is sharp on purpose. Agents that try to cross it are agents that are about to get themselves into trouble.

The agent sequence, end to end

Here is the entire happy path, the way an agent should walk it:

1. POST /api/v1/signup
   -> checkout_url

2. User pays and verifies posterly access
   -> first API key is created in the dashboard

3. POST /api/v1/connect/instagram/sessions
   -> connect_url + poll_url

4. Open connect_url for the user
   -> user approves provider OAuth in browser

5. GET poll_url
   -> status: connected

Five steps, three API calls, one human in the loop. Once status: connected comes back, the agent has everything it needs to start posting on behalf of the user.

Connect session status definitions

The poll endpoint returns one of eight statuses. Each one is something the agent can say to the user without invention.

• created: The connection link is ready. The agent should share connect_url and tell the user to open it.
• opened: The user opened the connect link in their browser. The agent can say "I can see you've opened the connection page".
• awaiting_provider: The user is on the provider's OAuth screen (Meta, Google, etc.). The agent can say "Almost there, just approve the permissions in your browser".
• awaiting_credentials: For manual platforms (Bluesky, Telegram), the user is entering credentials in posterly. The agent should be patient and not assume failure.
• connected: Done. The agent can move on and confirm the platform is live.
• failed: Something went wrong on the provider side. The agent should offer to retry.
• cancelled: The user backed out. The agent should ask if they want to try a different account.
• expired: The 30-minute window passed. The agent should create a new session.

Three of these (failed, cancelled, expired) are dead ends that need a fresh session. The other five are progress. The agent's reporting can be that simple.

The boundaries are intentional

We get asked why we don't make this flow "fully agentic" by accepting cards or OAuth codes through the API. The answer is that the boundaries are the product. Five guarantees define the shape:

1. Payment is required for API access. No API key without an active subscription. This keeps abuse and accidental cost out of the system.
2. Provider OAuth stays in the user's browser. Meta, Google, LinkedIn and the rest expect a real consent screen. We do not work around that and we do not want agents that do.
3. Agents never collect card details or provider passwords. Even when the user offers, the flow has nowhere to put them. That is by design.
4. API keys are created only after the paid user verifies access. No dangling credentials, no half-states for support to clean up.
5. Connection sessions expire after 30 minutes. Abandoned flows don't accumulate. Either it works promptly or it gets thrown away and the user starts over.

These rules cost us a little speed and they save us, and our users, a lot of risk. If you're building agents that need to onboard users to a SaaS, we recommend the same shape even if you're not building on posterly.

The industry is moving the same way

Days before we published this, Stripe shipped Link's wallet for agents and Issuing for agents, introducing Shared Payment Tokens (SPTs). The pattern Stripe is pushing matches the one we describe above: the agent never sees raw payment credentials, and the user pre-approves what the agent can spend. Stripe puts it directly: "The agent never gets access to your raw payment credentials."

Worth being precise about the use cases though. SPTs are built for consumer agentic commerce, the personal-assistant or shopping-agent flow where an agent makes a scoped one-time purchase against a token the user already approved. They are not a replacement for hosted checkout in recurring SaaS subscription signup, which is what POST /api/v1/signup covers and what Stripe Checkout itself is built for. Different problems, same boundary: the agent does not touch the card.

If anything, Stripe's launch is validation. The category is settling on the same shape: scoped credentials, user-approved, hosted wherever the sensitive bits actually live. Whether you're routing through hosted Checkout or issuing SPTs, the agent stays on the outside of the credential.

Where the rest of the agent surface fits

The signup flow is the entry point. After it, the agent has access to the same surface area as any human user of posterly:

• 51 MCP tools. Schedule posts, batch-create content, upload media, generate images and video with cost guardrails, find available time slots, sync analytics, manage webhooks. The full list is on the posterly MCP page.
• REST API. Same coverage as MCP, accessible from any agent that can make HTTP calls. The API reference has the full schema.
• OpenClaw skill. For chat-app agents that want one-shot tool access without running an MCP server, the OpenClaw skill wraps the same tools.
• 11 platforms. LinkedIn, X, YouTube, Facebook, Instagram, Threads, TikTok, Pinterest, Google Business Profile, Telegram, Bluesky. One agent action posts everywhere, with platform-specific options exposed when they matter.

What signup gives you is the door. The 51 tools are what's behind it.

Wire your agent against it

If you're building an AI agent and you want posterly's signup flow as your onboarding step, the integration is short:

1. Read the agent signup page. It documents the three endpoints, the safety boundaries, and the connect session statuses in machine-readable form.
2. Add the three API calls to your agent's tool list. The OpenAPI spec at /api/openapi describes them in full.
3. Map the connect session statuses to natural-language reports. Eight statuses, eight short strings. Done.
4. Test with a real signup. The flow works end to end in production, not just on paper.

The whole loop, from "user asks the agent to schedule a post" to "post is live on Instagram", can fit inside a single conversation. Signup is the part that used to be missing.

FAQ

Can an AI agent really sign someone up to a SaaS without collecting payment details?

Yes, if the SaaS exposes a public signup endpoint that returns a hosted-checkout URL. posterly's POST /api/v1/signup is exactly that. The agent never sees the card. The user pays in their own browser. Hosted checkout (Stripe Checkout, Paddle, Lemon Squeezy) is the right primitive for this.

Why does the agent need to wait for billing before getting an API key?

To avoid dangling credentials. If an API key were returned before payment, and the user abandoned checkout, you would have a credential pointing at no paid account. That is messy operationally and weaker security. Requiring active billing keeps the API key tied to a real, paying user.

What about platforms that don't expose OAuth, like Bluesky or Telegram?

The same flow applies, but the user enters credentials in posterly's own browser flow rather than a provider OAuth screen. The status awaiting_credentials reflects that. The agent still never touches the credentials.

How does this compare to a generic OAuth client credentials flow?

Client credentials authenticate the agent to posterly. They do not authenticate a user to a provider (Meta, Google, etc.). The connect session flow is what bridges the agent's API access to a specific user's social accounts. Both pieces are needed.

Is the flow specific to posterly or is it a pattern other SaaS could adopt?

It's a pattern. Any SaaS that needs AI agents to onboard paying users can use this shape: a public signup endpoint that returns a hosted-checkout URL, a connect-session endpoint that returns browser handoff URLs and a poll URL, and a status enum that maps cleanly to natural-language progress reports. The specifics (Stripe Checkout, OAuth providers, 30-minute expiry) can vary. The boundaries should not.

Where do I find the OpenAPI spec?

poster.ly/api/openapi. Both the signup and connect-session endpoints are documented there, alongside everything else posterly exposes.

Which AI agents work with this today?

Any agent that can make HTTP requests (custom GPTs, ChatGPT with Actions, Hermes, your own scripts) and any MCP-capable client (Claude Desktop, Cursor, Windsurf, Cline, ChatGPT Desktop). The OpenClaw skill packages the same tools for chat-app agents like Telegram and WhatsApp bots.

Try it

The agent signup flow is live. The page at poster.ly/agents/signup is both human-readable and crawlable by agents that discover capabilities by reading public pages. If you're building an AI agent and you want it to onboard paying users to a social media tool, start there.

If you'd rather see the broader agent surface first, the AI agents overview lists every integration point: MCP, REST API, OpenClaw, and the 51 tools the agent can call once a user is signed up. The MCP setup guide covers the stdio and HTTP transports for Claude Desktop, Cursor, Windsurf and the rest.

Agents that can sign users up are a different class of product than agents that need pre-existing accounts. We built this flow because we want posterly to live in the first category. If you're building anything similar, we hope the shape is useful.