All jobs

Create a Notion Onboarding Page for Every New Customer Through an API

Yes. Your app starts one session per new customer; the agent researches the company, fills a page from your Notion template and returns its link.

What the agent does

This job has no repository. The session's input is a short prompt with the new customer's company name and domain, which your backend fills in at sign-up, and the session names one connection: your Notion workspace, connected once through Notion's remote MCP server at https://mcp.notion.com/mcp. That server is in Rush's connector catalog with sign-in by OAuth, and it lets the agent search, read, create and update pages and databases in the workspace you authorized. The agent can reach nothing else in Notion that your sign-in cannot.

The agent starts with the customer. It opens the company's website in the sandbox's browser from the domain it was given and reads the pages a customer-success lead would: the home page, the product or services pages, the about page, and any pricing, customers or careers page that says who they sell to and how large they are. It writes down what the company does, who its customers are, the products that matter for your onboarding, and any public names and roles listed for the leadership or the team that is likely to own the account. It works from what the site says and notes when something was not found, rather than filling a section with a guess.

Then it works in Notion. It searches the workspace for the page titled Onboarding template, reads its structure (the headings, the toggles, any placeholder text and the properties if it lives in a database), and duplicates it into the Customers page or database so your template is never edited. On the copy it fills the company summary section with what it found, the goals section with the outcomes the customer's own site suggests they care about, worded as questions to confirm on the kickoff call, and the contacts section with the public names and roles it found, each with the page it came from. It sets the page title to the company name and leaves every other section of the template as it was, for your team to fill in during onboarding.

Last, it reads the new page back to check that each section it was asked to fill has content and that no other page changed, and ends the turn with JSON: page_url, the link to the new Notion page, and summary, two or three sentences on the company for whoever picks up the account.

Start it with one API call

POST https://api.prix.dev/o/{org}/sessions with this body:

{
  "agent": "claude",
  "input": "A new customer signed up: company Northwind Robotics, domain northwind-robotics.example. Research the company on its website: what it does, who it sells to, its main products, and the public names and roles of its leadership. Then in Notion, find the page titled Onboarding template, duplicate it into Customers, and title the copy with the company name. Fill only its company summary, goals and contacts sections: goals as questions to confirm on the kickoff call, contacts with the page each name came from. Write 'not found on the website' where the site says nothing. Change no other page and do not edit the template. Read the new page back to check it, then return only JSON with page_url and summary (two or three sentences on the company).",
  "connections": [
    "notion"
  ]
}
  1. Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
  2. Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
  3. Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

What comes back

The answer is the JSON with page_url and summary, in the session's result and in the run.completed webhook's data.result, which carries the result in full up to 16 KiB; this one is a few lines. Your backend parses it and posts the link where your team will see it: the customer record in your CRM, the account's Slack channel, or the calendar invite for the kickoff call. The page itself lives in your Notion workspace under Customers, in your template's layout, with the summary, goals and contacts filled and every other section untouched.

Before the kickoff call, the account owner reads the page and confirms the contacts and goals with the customer. Because the agent cites the page each contact came from and writes 'not found' instead of guessing, a reviewer can tell at a glance what was found and what still needs asking. The session transcript, GET /o/{org}/sessions/{id}/messages, records each page the agent visited and each Notion tool it called, so if anything on the page looks wrong you can see where it came from.

Run it on every customer sign-up

Start the session from the code that handles a new sign-up, or from a job that reads new accounts from your billing or CRM system. Put the customer's company name and domain into the prompt, send an Idempotency-Key built from the customer's id so a retried sign-up handler returns the same run instead of creating a second page, and save the execution_id from the 202 against the customer.

Set a webhook URL on the API key. When the turn ends Rush POSTs run.completed with execution_id and result; your handler verifies the signature, looks up the customer, parses page_url and posts it to the account owner. A run.failed event, or JSON that does not parse, goes to a queue a person checks, so no customer starts onboarding without a page.

The use case this job follows, with its automation and trigger: Run an agent per customer task.

Why run it on Rush?

A sign-up handler should answer in milliseconds, and researching a company and writing a Notion page takes minutes. Starting a Rush session returns a 202 at once, and the work happens in its own sandbox with a browser for the research and your Notion connection for the page, so your app never holds a long request open or runs a browser itself.

Each page comes with a record. The transcript keeps every website the agent read and every Notion call it made, which is what a customer-success lead needs before trusting a page that a person did not write. Sign-ups that arrive together each get their own session and run at once, up to the key's concurrent run limit, so a busy day does not create a backlog of onboarding pages.

Frequently asked questions

How do I connect our Notion workspace?

Once, with the key: POST /me/connections with {"type": "mcp", "name": "notion", "url": "https://mcp.notion.com/mcp", "auth": {"mode": "oauth"}}. It answers 202 with an authorize_url that the key's creator opens while signed in to the Rush console, and approves in Notion. After that, every run names it as "notion" in connections.

Can the agent change pages other than the new one?

It can reach what your Notion sign-in can reach, so the prompt tells it to duplicate the template, fill three sections and change nothing else, and to read the page back before it answers. For a tighter boundary, approve the Notion connection with an account that can only see the template and the Customers page.

What if the customer's website says very little?

The agent writes 'not found on the website' in the sections it could not fill and says so in summary. Your team then knows which questions to ask on the kickoff call, which is better than a page filled with plausible guesses.

Does it work with a Notion database instead of a page?

Yes. If Customers is a database, the agent creates the new entry in it from your template and sets the title property to the company name. Name any other properties you want filled, such as the plan or the account owner, in the prompt, and pass their values with the customer's name and domain.