Configure, import and manage an Action

Open the correct workspace#

Sign in as the workspace owner or an admin, open Actions and choose the website the operation serves. Business can configure reads; Scale can also configure writes. The page offers task starters for a custom API, WooCommerce, built-in support and return requests, and Shopify when a store connection exists.

If the page says Actions are not configured on the server, contact Reesponder support rather than changing your website code. An inactive plan, an archived website or missing server configuration can prevent execution independently of your saved form.

Do not start by duplicating an existing working definition. First check whether that website already has the same task. A second similar definition can complicate assistant selection and create separate activity records for an operation your team intended to manage once.

Describe the task precisely#

Use a customer-facing name between 3 and 80 characters and a description between 10 and 600 characters. Explain the task, the circumstances in which it should run and any important distinction from similar Actions. For example: “Check the delivery status of an order belonging to the verified customer. Ask for the order reference.”

For custom HTTP, choose Read · GET request or Write · POST request, visitor confirmation. The endpoint is fixed. A read must genuinely avoid mutations: selecting read mode cannot make an endpoint with side effects safe. Keep each write limited to one understandable operation.

The customer-facing name also appears in the operation card. Write it as something the customer can recognize when asked to confirm, such as “Submit a delivery-change request”, rather than an internal service name or a vague “Process customer”.

Set the endpoint and credential#

Enter a public HTTPS URL without an existing query string, fragment or embedded username and password. Custom HTTP credentials are optional bearer tokens. WooCommerce uses consumer_key:consumer_secret. Shopify credentials come from its authorization flow, not a pasted merchant app secret.

The credential field is write-only. On an existing Action, leaving it blank preserves the saved credential when the provider and endpoint stay the same. Changing the provider or endpoint clears the previous credential unless you enter a replacement. Check this when a previously working Action suddenly fails after an edit.

Use the final handler URL. An endpoint that redirects from a trailing slash or another hostname will not be followed. Have your developer verify the configured URL directly, including its TLS certificate and authenticated response.

Collect only what the task needs#

Define up to eight input fields and eight custom HTTP result mappings. Field keys are API names; labels are the words customers see. Include the required reference or identifier, but do not use a visitor-supplied email field as proof of identity. Keep email verification enabled for private records.

Result mappings identify scalar JSON paths such as order.status. Review the label and content as customer-facing copy. An Action can return a useful reference and status without exposing an entire provider record.

Required fields are collected before a proposal can execute. Mark an optional comment optional rather than inventing a placeholder that your service might interpret as a real instruction. Keep result labels stable enough for staff to understand activity later.

Import a developer’s HTTP template#

Import HTTP template reads a JSON file up to 64 KB into the form. It accepts only the portable HTTP configuration: name, description, mode, endpoint, identity requirement, inputs and result mappings. Imported files do not choose a workspace or website, install credentials or enable an Action.

Choose the website yourself, review the destination, enter any bearer token and save. A write template still requires Scale and a real confirmed test. Do not treat a template received from someone else as already reviewed or connected. See the complete example in the HTTP contract.

A portable template is a reviewed configuration starting point. It is not an account export or a credential transfer, and it cannot carry another workspace's authorization into your website.

Test, enable, pause and delete#

Open the saved draft, run a test and inspect the actual result. Once the current revision succeeds, select Enable action. Any subsequent save pauses the Action, increments its revision and invalidates the previous test. Repeat the test after even a small mapping or endpoint edit.

Pausing or editing cancels pending proposals. Deleting removes the definition and preserves its activity history subject to retention. These controls do not undo a request already in flight or reverse a completed external operation. Check the destination system before recreating or rerunning an uncertain write. Each website supports at most 20 definitions.

Schedule edits around any customer activity your team is investigating. A pause protects future and pending work; it cannot stop a destination that has already received a request. Use the run reference to inspect that destination separately.

Worked example: create an owned-order lookup#

Select the website whose customers will ask about orders. Create a custom HTTP read named “Check order status”. Describe its trigger: use it when a customer asks for the current state of an order they own, and ask for the order reference first. This description keeps it distinct from general delivery policy answers.

Use an illustrative endpoint such as https://support.example.com/reesponder/order-status; this placeholder must be replaced with your actual deployed handler. Save the service bearer credential separately. Add required input order_reference with customer label “Order reference” and leave email verification enabled. Map the actual response paths for status and reference.

Save a draft and test an order whose expected state and owner email you know. Test that same reference with a different email and confirm no private result is returned. If either path is wrong, fix the endpoint or mapping and save again. A draft that happens to pass one happy-path test still needs this ownership review.

Enable the tested revision, then use the public storefront to ask the original question. Confirm input collection, email verification, the displayed summary and the matching Activity & requests record. This final pass tests task selection and visitor controls that the draft test does not exercise.

Review the saved definition before launch#

Check the selected website, provider, mode, destination, verification requirement and every mapping together. A correct URL with the wrong website is still the wrong installation. A useful response with the wrong scalar path can omit or mislabel the result. Inspect a known fixture rather than accepting any green test.

Record the version you enabled and the test cases your team reviewed. Verify that the Action appears only where intended and that cancelling a live proposal leaves the destination unchanged. When editing a credential or endpoint later, repeat the same checks before re-enabling.

Prepare the configuration with your developer#

Agree the contract before opening the form. Ask for the exact final HTTPS URL, whether the task is a read or a write, the supported service credential, required input keys and an example safe response. For private data, agree how the endpoint matches the supplied verified email to the record's owner. A field called “Customer email” is not a substitute for that check.

For a write, obtain the destination's idempotency behavior and a recovery procedure for a lost response. Ask which business states permit the change and which normal rejections should return a factual status. The endpoint should not depend on the assistant improvising those rules.

Review an example response with real field nesting but synthetic values. Decide what each mapped label means to a visitor. Map the customer-safe summary; do not map a debugging object just because the API already returns it. Dates and currency should be represented clearly by the adapter.

Finally, choose safe test fixtures. A read fixture needs known ownership and known output. A write fixture needs a disposable destination record and a plan for cleanup. Keep any provider keys outside the template file, screenshot and conversation. Completing this short agreement makes the form a precise implementation step rather than an experiment against production data.

Handle edits, credentials and imports deliberately#

Suppose the order service moves from one host to another. Changing the endpoint clears the old credential unless you supply a replacement. Enter the credential appropriate to the new destination, save, test and enable again. Do not assume a blank credential field means the previous service token was transferred across hosts.

If only a result path changes, a new save still creates a revision and pauses the definition. Test the new path against a known response. If the provider returns delivery.status while the mapping still says order.status, the HTTP request may succeed but produce no useful customer result.

When importing a template, inspect its destination and mode before entering a secret. An import fills the editor; you must choose the website and complete the normal save, test and enable flow. Keep the reviewed template as a useful configuration record without credentials, and update it when your developer changes the contract.

If the website has reached its limit of 20 definitions, review unused drafts and overlapping tasks. Deleting an obsolete definition removes future availability but preserves historical activity subject to retention. Avoid consolidating materially different authorization or confirmation rules merely to reduce the number of definitions.