The /pages endpoint gives you full programmatic control over UniLink pages — create, read, update, and archive pages along with their full block structure via the REST API.
- Base path is
https://unilink.us/api/v1/pages— supports GET (list + single with blocks), POST (create), PUT (update), and DELETE (archive). - Single-page responses include the full
blocksarray describing every content block on the page. - Primary use cases are agency bulk page creation and external page management tools syncing content from third-party systems.
The UniLink pages endpoint is the most powerful entry point in the API — it exposes the same page creation and editing capabilities available in the dashboard, but programmatically. Agencies managing dozens or hundreds of client pages can automate page creation from templates, sync page content from external systems, or build their own branded management interface on top of UniLink. Everything the dashboard can do with a page, the API can do at scale.
What the Pages Endpoint Does
The /pages endpoint supports five operations. GET /pages returns a paginated list of all pages belonging to the authenticated account. The list response includes page metadata: id, slug, title, published (boolean), url (the public URL at unil.ink/{slug}), created_at, and updated_at. Crucially, the list response does not include the blocks array for performance. GET /pages/{id} returns the full single-page response including the complete blocks array. POST /pages creates a new page. PUT /pages/{id} updates an existing page's metadata or blocks. DELETE /pages/{id} archives the page — it becomes unpublished and invisible to visitors but is retained in the dashboard.
The blocks array is the heart of a UniLink page. Each element in the array is a block object representing one content section: a link block, a social icons block, a text block, a product card, an image, or any of the 25+ supported block types. Each block has a type string (for example, link, image, social, product), a position integer defining its order on the page, and a settings object whose fields vary by block type. When you GET a single page, you receive all blocks in position order. When you PUT to update a page, you can replace the entire blocks array or patch individual blocks using their id.
Creating a page via the API produces the same result as creating one in the dashboard. The page is immediately accessible at unil.ink/{slug} if you set published: true, or it remains a private draft if published: false. Pages created via the API follow the same slug uniqueness rules — each slug must be unique across all pages on the account. The API enforces the same block type validation as the dashboard, so invalid block configurations are rejected with a 422 error and a descriptive details object.
How to Get Started
- Generate an API key with write scope from Settings → API — write scope is required for POST, PUT, and DELETE; read scope is sufficient for GET-only use cases.
- Fetch an existing page with its full block structure:
GET https://unilink.us/api/v1/pages/{id}. Study theblocksarray structure to understand the block types and settings your account uses. - Create a minimal test page: POST to
/pageswith a JSON body containingtitle,slug,published: false, and an emptyblocks: []array. Verify the page appears in the dashboard as a draft. - Add a link block to the page: PUT to
/pages/{id}with ablocksarray containing one block of typelinkwith asettingsobject. Verify the block renders in the dashboard page editor. - Publish the page by sending PUT with
{"published": true}. Confirm the page loads at its public URL.
How to Use the Pages Endpoint
- List all pages:
GET /pages?limit=100returns metadata for up to 100 pages. Use cursor pagination to fetch more. Filter with?published=trueor?published=falseto separate live pages from drafts. - Fetch a page with its blocks:
GET /pages/{id}returns the full page including theblocksarray. Use this before any PUT update to read the current state and avoid accidentally overwriting blocks you did not intend to change. - Create a page from a template: Prepare a JSON page object with a
blocksarray pre-populated from a template. POST it to/pageswith a unique slug. For agency workflows, parameterize the title, slug, and link URLs to generate unique pages per client. - Update specific page fields: PUT to
/pages/{id}with only the fields to change. To update just the title:{"title": "New Title"}. To replace all blocks: include the fullblocksarray with updated positions and settings. Omit blocks you want to keep unchanged. - Archive a page: DELETE to
/pages/{id}. The page is unpublished and its URL returns 404. The page record is retained in the dashboard under archived pages for 30 days and can be restored manually.
Key Settings
| Setting | What It Does | Recommended |
|---|---|---|
| slug | The URL path for the page at unil.ink/{slug} — must be unique per account | Use lowercase letters, numbers, and hyphens only; keep under 50 characters |
| published | Controls whether the page is publicly accessible | Create as draft (false), review in dashboard, then publish via PUT when ready |
| blocks array | Ordered list of content blocks defining the page's visual structure | Always read the current blocks before updating to avoid overwriting unintended content |
| block.position | Integer determining vertical order of blocks on the page | Use sequential integers starting at 1 and increment by 1 per block |
| block.settings | Block-type-specific configuration (URL, label, image URL, etc.) | Refer to the block type schema in the API reference for required and optional settings fields |
slug, title, and the URLs inside link blocks. Deep-clone the template object for each client and POST it with the client-specific values. This approach creates consistent, brand-aligned pages across all clients in seconds.
Get the Most Out Of the Pages Endpoint
Build a two-phase creation workflow: create pages as drafts first, then publish in a second step. This gives your team or your clients the opportunity to review each page before it goes live. For agency use, automate the draft creation step and send clients a dashboard preview link. Only publish once the client approves — preventing half-finished pages from going live accidentally.
When syncing page content from an external system — for example, pulling product data from a Shopify store and creating UniLink pages for each product — use the external system's ID as part of the UniLink page slug. For example, slug: "product-shopify-12345". This creates a stable mapping between systems that you can query in either direction and use to detect which pages need updates when the product data changes.
The blocks array update requires careful handling to avoid data loss. When you PUT a full blocks array, it replaces the existing blocks entirely. If your integration manages only some blocks on a page (for example, syncing link blocks from an external URL manager while leaving header and footer blocks unchanged), fetch the current page first, modify only the relevant blocks, and send the full updated array. Never send a partial array when you intend a partial update.
Use the updated_at timestamp in list responses to build incremental sync pipelines. Store the last-synced timestamp per page in your system. On each sync run, fetch pages with ?updated_after=LAST_SYNC and process only those that have changed. For bidirectional sync where your system and UniLink can both update a page, use updated_at to implement last-write-wins or a conflict detection strategy before sending updates.
Troubleshooting
| Problem | Cause | Fix |
|---|---|---|
| 409 Conflict when creating a page | A page with the same slug already exists on the account | Check for an existing page with that slug first; either update it via PUT or choose a unique slug |
| blocks array reset to empty after PUT | PUT body included "blocks": [] instead of omitting the blocks field | Omit the blocks field entirely if you only want to update page metadata; include all current blocks plus changes if updating blocks |
| 422 on block creation with valid-looking settings | A required settings field for that block type is missing | Fetch an existing working block of the same type and compare its settings object to your payload — check the API reference for required fields per block type |
| Page published but not loading at public URL | Propagation delay or Cloudflare cache serving old 404 | Wait 30–60 seconds and hard refresh; if still not loading, confirm published=true in a GET response and check for slug conflicts |
- Full CRUD access enables complete agency workflows — create, manage, and archive pages at any scale
- Full blocks array in single-page GET responses exposes the complete page structure for sync and migration workflows
- Slug-based URL structure makes it straightforward to map external IDs to UniLink page addresses
- Draft/publish workflow lets you review pages before they go live, even in fully automated pipelines
- PUT replaces the full blocks array — partial block updates require fetching the current state first
- Block type schemas vary — must reference API docs per block type to get settings fields right
- No bulk create endpoint — each page requires a separate POST request in large agency workflows
Does the list endpoint return page blocks?
No. GET /pages returns metadata only for performance. To get the full blocks array, fetch an individual page with GET /pages/{id}.
Can I partially update page blocks without replacing them all?
When you include a blocks field in a PUT request, it replaces the entire blocks array. To update only specific blocks, first fetch the current page, modify the relevant blocks in the array, and send the complete updated array in your PUT request.
What block types are supported?
UniLink supports 25+ block types including link, social, image, text, product, video, form, countdown, banner, and more. Each type has its own settings schema. Refer to the API reference's block types section for the complete list and required fields per type.
Does DELETE permanently remove a page?
No. DELETE archives the page — it becomes unpublished and is retained in the dashboard under archived pages for 30 days. You can restore it from the dashboard within that window. Permanent deletion is only possible through the dashboard.
Can I create a page under a custom domain via the API?
Pages created via the API use the default unil.ink/{slug} URL. Custom domain assignment is configured in the dashboard under Settings → Domains. Once a custom domain is assigned at the account level, pages served via that domain also appear at the custom URL.
- The pages endpoint is at
https://unilink.us/api/v1/pages— supports full CRUD including block structure management. - List responses include metadata only — fetch
GET /pages/{id}for the fullblocksarray. - PUT with a
blocksfield replaces all blocks — always read current state first to avoid overwriting content. - Create pages as drafts (
published: false), review them, then publish in a second PUT step. - Use external system IDs in page slugs to maintain a stable mapping for bidirectional sync workflows.
Ready to manage UniLink pages programmatically? Generate your API key at app.unilink.us under Settings → API and start building your page management workflow today.