> ## Documentation Index
> Fetch the complete documentation index at: https://docs.contactbutton.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Set up with a coding agent

> Give Codex, Claude Code, or another tool-capable coding agent a safe, verifiable Contact Button setup workflow with scoped tokens and human confirmation.

Contact Button is designed so a person can describe the result they want and let an authorized coding agent perform the deterministic setup through REST or MCP.

## Give the agent this prompt

```text theme={null}
Set up Contact Button for me using the official instructions at:
https://agents.contactbutton.com/.well-known/agent-skills/contact-button/SKILL.md

First inspect my current Contact Button workspace and make a plan.
Read before writing, keep stable resource IDs, and use idempotency keys.
Ask before publishing, buying a phone number, changing DNS, or taking
another paid or externally visible action. Never ask me to paste secrets
into chat; tell me which secret names to add through a secure channel.
After publishing, verify the HTML, Markdown, manifest, and agent metadata.
```

Add the desired outcome after this prompt. Include the audience, primary contact actions, brand constraints, required domain, and which existing workspace the agent should use.

## What the agent should ask for

The agent may need:

* A Contact Button API token stored in the host's secret manager as `CONTACTBUTTON_TOKEN`
* The target workspace name or UUID when more than one is accessible
* Approval for a final preview and publish
* Approval before creating or changing DNS
* A Telnyx account only if the experience uses phone or SMS features

The agent should not ask for raw secrets in chat. If signup is required, it starts the API signup, then the human supplies the one-time code delivered directly to their email.

## Expected execution

1. Read the agent skill, OpenAPI contract, and relevant task guide.
2. List accessible workspaces and ask the human to disambiguate only if needed.
3. Inventory existing Pages, domains, buttons, forms, and apps before changing them.
4. Make additive draft changes with stable UUIDs and idempotency keys.
5. Report any requested outcome that the current public API cannot represent. Do not silently fall back to fragile browser automation.
6. Present the planned public URLs and any paid or DNS actions.
7. Publish only after explicit approval.
8. Read the public result back as HTML, Markdown, manifest JSON, and an A2A Agent Card when enabled.
9. Report parity problems, IDs, URLs, and human-only follow-up work.

## First dogfood test: rebuild contactbutton.com

Use the existing workspace identified by the human as **domain 3**. Treat that label as a hint, not an authorization boundary: list the token's accessible workspaces and confirm the returned workspace identity before writing.

Build the new marketing Page as a separate draft. Do not modify the current `www.contactbutton.com` mapping during composition.

Recommended sequence:

1. Inventory the existing workspace, Pages, custom domains, buttons, forms, booking types, and published links.
2. Create a draft Page with a temporary `button.contact` slug, `robots_index: false`, and `llms_enabled: true`.
3. Add only content and components supported by the current documented API. If Page-builder layout blocks are not yet exposed, stop and report the missing operations as product feedback rather than claiming the site is complete.
4. Preview with humans and agents. Verify heading order, keyboard access, contrast, semantic links and forms, structured data, `index.md`, `manifest.json`, and `llms.txt`.
5. Keep the existing marketing site available at `learn.contactbutton.com` before moving `www`.
6. Add and verify `www.contactbutton.com` as a custom domain without removing the draft's `button.contact` identity.
7. Change the publish destination and DNS only after approval and a documented rollback check.

This test is intentionally strict. Every point where the agent cannot proceed from the public documentation and API should become a focused API or documentation ticket.

## Completion standard

The setup is not complete merely because an API returned `200`. The agent should show that:

* The intended workspace owns every new resource.
* Existing published resources still behave as before.
* The public HTML works without JavaScript for core reading and navigation.
* Machine-readable representations contain the same public facts and no secrets.
* Material public actions advertise and enforce their confirmation requirements.
* Custom-domain DNS and TLS are verified before the domain becomes canonical.
* Rollback consists of returning the publish destination or DNS record to the previously recorded value, not deleting shared data.


## Related topics

- [Update notification and agent policy settings](/api-reference/workspaces/update-notification-and-agent-policy-settings.md)
- [Get notification and agent policy settings](/api-reference/workspaces/get-notification-and-agent-policy-settings.md)
- [Connect Telnyx](/guides/telnyx.md)
- [Contact Button webhooks](/guides/webhooks.md)
- [Changelog](/changelog.md)