Endpoint Detail

Overview

Endpoint Detail is the page that handles all settings for a single endpoint. From this one screen you can:

• View and edit endpoint info (name, description, URL, version)
• Toggle active / inactive
• Deploy and redeploy to production
• Manage default API key
• Add and remove required fields
• Configure webhooks
• Delete the endpoint

Collaboration key management (issuing keys, invitations, permissions) is handled on a separate page. See Collaboration Keys for details.

If you're participating as a collaborator, only the sections you have access to are shown (owner-only sections are automatically hidden).

How to get here

• Top menu APIs → Click the endpoint name in the list
• Dashboard Recent Activity → Click the endpoint
• Auto-navigated after completing Onboarding Step 1

---

Free plan warning banner

Shown at the top when using the Free plan. On the Free plan, feel free to create and experiment with endpoints as much as you like. They are automatically cleaned up 7 days after creation, but you can always create new ones — so go ahead and try things out.

Active/Inactive and Deploy buttons

Owner-only area.

• Active/Inactive button (Power icon): Use this when you want to temporarily pause API calls across all environments. Calls are rejected while inactive, but data is preserved.
• Deploy to Production button (Sandbox tab only):
  • Copies the current sandbox settings to production
  • Condition: Must have completed at least 1 test call in sandbox before it becomes active

If a collaborator is accessing the page, a Request Deploy button appears instead. It sends a deployment request message to the owner.

Environment tabs

Below the header bar, there are Sandbox | Production tabs. The two environments are completely independent.

The recommended workflow is: Test in sandbox and discuss with collaborators → Deploy to production → Operate. When changes are needed, modify in sandbox first and redeploy.

Sandbox

• Environment for calls with sandbox API keys (tm_test_)
• For testing only. Experiment freely before going live
• Sandbox data is automatically deleted after 30 days (all plans)

Production

• Environment for calls with production API keys (tm_live_)
• For live operations. Records are kept for at least 60 days, then removed a whole month at a time. Export what you need to keep as it arrives — set up a webhook, or poll the list API
• Before production deployment, production key calls are rejected and not logged

Overview card

Section containing the endpoint's basic information.

Item	Description
Description	Endpoint description. Owner can edit inline on the Sandbox tab
Endpoint URL	The actual API call address. Send POST/GET/PUT/DELETE requests to this URL. Copy button provided
Version	Configuration version. Increments with each deployment
Created	Endpoint creation time
Updated	Last setting change time (Sandbox)
Published	Production deployment time (Production tab only)

Default API Key

Owner-only area.

• The default API key issued when the endpoint was created
• Used for authentication on the Test & Integration Guide page, accessed via the View Docs button on the right
• Show / Hide toggle to conceal or reveal the key on screen
• Regenerate button: The previous key is immediately invalidated. Use only when exposure is suspected

When a collaborator accesses the page, this section is replaced with their assigned collaboration key card.

Collaboration Keys

Only a summary card is provided here — key creation, invitations, and permission management are done on a separate management page.

• Owner view: View all button and per-collaborator summary (name, invitation count)
• Collaborator view: Permission badges for the key assigned to you

See Collaboration Keys for detailed instructions.

Required Fields

Define JSON fields that must be included in API calls. For a detailed explanation, see Create New Endpoint.

• To add or edit fields, click the Edit button
• While editing, you can add, delete, and change field types. Finish with Save or Cancel
• Saving updates the Sandbox configuration — to apply to production, you need to redeploy
• Even after deployment, modifying required fields does not affect existing stored data. The updated field rules apply only to new incoming calls

Webhooks

Owner-only area.

When an API call is successfully processed, a secondary request can be sent to the specified webhook URL. Data storage always completes regardless of webhook success.

Input fields

• Webhook URL: Address to receive webhooks (HTTPS recommended)
• Auth Header (optional): Authentication header key. Default Authorization
• Auth Value (optional): Authentication header value. Example: Bearer abc123

For webhooks that don't require authentication (simple receivers, URL-embedded tokens, etc.), leave the auth fields empty.

Webhook policy summary

• Timeout: Must respond within 15 seconds. Treated as failure if exceeded
• Response code: A 2xx means "I received it", not "it succeeded". Return 2xx even when your own processing fails, and record that failure in your own system. A 5xx tells us the delivery never landed, so we resend the same record on the retry schedule below and your receiver runs the same work every time
• Retry: Production is 6 attempts total — the first delivery plus 5 retries at 30s, 2m, 10m, 1h, 4h (about 5 hours). Sandbox is 4 attempts total — the first delivery plus 3 retries at 30s, 2m, 10m (about 12 minutes)
• Retried: 5xx, 429, timeouts, and connection errors. A Retry-After on a 429 makes us wait longer, never shorter than the default gap
• Not retried: Any 4xx other than 429, including 409. Fix the setting and the next call goes through
• Checking failures: Failed and in-flight deliveries show up under Webhook delivery on the logs screen. Successful deliveries are not recorded
• Email alert: When we give up on a delivery — retries exhausted, or a permanent response — we email you on every plan, Free included, but only in production — at most one message per endpoint per day, with no recovery notice. Collaborator webhook failures are not emailed, since you cannot change that URL
• Idempotency: Every attempt carries the same X-3minapi-Record-Id. Use it to detect duplicates
• Signature: every request carries an HMAC-SHA256 signature (webhook-signature). See Webhook signing secret below for the details

Webhook signing secret

Sits just below the webhook settings card. It is not owner-only — collaborators can see it too, because a webhook a collaborator receives at their own X-Webhook-Callback URL is signed with the same secret.

• It differs per environment — the Sandbox tab and the Production tab hold separate secrets. Use the one for the environment you are receiving in
• Both the owner and collaborators can view it
• Only the owner can reissue (rotate) it. The reissue button does not appear on a collaborator's screen
• It is not a value to rotate on a schedule. Reissuing is what you do when a secret has leaked
• After a reissue, both the new and the previous signature are sent for 24 hours. Swap the value on your receiving server at any point in that window and no delivery is lost. During the grace period the card shows a banner with the expiry time

For what to actually do with this value, see Verifying the webhook signature.

Webhook payload

When an API call is processed, the following JSON payload is sent to the webhook URL. You can view the actual format by expanding the Webhook Payload Example section in the screenshot.

Field	Description
id	Unique ID of the stored record
operation	Action performed (create, update, delete)
status	Processing result (success, failed)
endpoint_slug	Endpoint identifier
payload	The original JSON data sent by the caller, included as-is (null for delete)
target_record_id	Target record ID (included for update/delete)
processed_at	Processing completion time

Collaborator webhooks

If collaborators need webhooks, they can set their own by including X-Webhook-Callback and other headers in their API request. Collaborator webhooks operate independently from owner webhooks, and the payload format is identical. See Test & Integration Guide for detailed setup instructions.

Collaborator webhooks get the same retry policy and the same signature as owner webhooks. The secret used to verify them is in the Webhook signing secret card above.

Danger Zone

Owner-only area.

• Delete Endpoint button
• Deletion immediately and permanently removes:
  • The endpoint configuration itself
  • All API records in sandbox and production
  • Related statistics / deployment requests / webhooks / collaboration keys
• Collaborators also lose access
• Cannot be undone — you must type the endpoint name in the confirmation dialog to proceed

Right sidebar

The right side of the detail page shows different quick cards depending on the environment.

API call records

Navigate to a page where you can view the results of API calls to this endpoint. You can check request success/failure, payloads, webhook status, and more in detail.

Sandbox test

Shown on the Sandbox tab.

Navigate to a page where you can test API calls directly in the browser and check integration methods. See Test & Integration Guide for details.

Production console

Shown on the Production tab, after deployment, for the owner only.

A console for managing production data directly from the dashboard. Useful for pre-populating product listings or announcements that collaborators will retrieve via GET. Supports POST (create), GET (read), PUT (update), and DELETE. The console runs with the owner's API key, and collaborator webhooks are not triggered. If the owner webhook is configured, it fires normally. See Production Console for details.

Deployment request notification

Shown on the Sandbox tab.

Shown when a collaborator has requested production deployment. This notification is also sent via email, so you won't miss it. Click the View all button to see the full deployment request history.

---

Troubleshooting

• Deploy button is disabled: Either no test calls have been made in sandbox, or the latest sandbox version is already deployed to production. Run a test in sandbox first
• Production tab has no records: Production calls are rejected until deployment, so no records are logged. Check if deployment was successful and whether tm_live_ keys are being used
• Required fields changed but not reflected in production: Sandbox changes are not automatically applied to production. Click Deploy to Production again
• Webhook isn't arriving: Webhook servers must respond within 15 seconds. Check whether the server is publicly accessible and using HTTPS. Platforms like Discord and Slack have their own rate limits — if too many webhooks fire in a short time, some may be blocked. Check the receiving platform's rate limit policy as well