Fill a field from a provider, record by record.
An enrichment field calls a provider action for each record and keeps the answer. Five calls take you from nothing to a filled field. Creating the field costs nothing; only a run calls the provider.
1. Find the action's inputs
Get action parameters lists what an action needs, and the schema_version
you create the field from.
curl https://api.appenda.app/v1/integrations/leadmagic/actions/email_finder \
-H "Authorization: Bearer $APPENDA_API_KEY"
Each entry in inputs has a key, a type, whether it is required, and
what it accepts: a field, a fixed value or a template. requires.one_of names
inputs where any one group is enough.
2. Create the field
Send the action, the schema_version from step 1, and one binding per input:
{"field": "<field key>"}, {"value": …} or {"template": "Find {company_name}"}.
curl https://api.appenda.app/v1/tables/tbl_67ad65ba34a7bbfc643711b8531cba3f/enrichment-fields \
-H "Authorization: Bearer $APPENDA_API_KEY" \
-H "Content-Type: application/json" \
-d '{"name": "Work email", "provider": "leadmagic", "action": "email_finder", "schema_version": 2, "inputs": {"domain": {"field": "company_domain"}, "first_name": {"field": "first_name"}, "last_name": {"field": "last_name"}}}'
The field's key comes from name: Work email becomes work_email, and a key
the table already has takes _2, then _3. Each mistake is refused, with param
naming the input. Send "dry_run": true to check the field without creating it.
3. Start a run
A run names the field, which records to reach, and the most it may spend. On a
key you connected, cap it with max_rows:
curl https://api.appenda.app/v1/runs \
-H "Authorization: Bearer $APPENDA_API_KEY" \
-H "Content-Type: application/json" \
-d '{"kind": "enrichment", "table_id": "tbl_67ad65ba34a7bbfc643711b8531cba3f", "field_id": "fld_1e57b877a78db86124936f976015f646", "credential_id": "cred_772ad6fd9b6f3d01a25cb34c169bf1b9", "options": {"force": false, "mode": {"count": 500, "kind": "first"}}, "spend_cap": {"max_rows": 500}}'
A run on Appenda's keys spends credits and is capped with max_credits instead.
See Credits. The run answers 202 and works in the
background. If your role needs approval for it, the answer is an approval to
poll instead.
4. Check the run
curl https://api.appenda.app/v1/runs/job_d60ef6b2d188d2801bd33bf129195874 \
-H "Authorization: Bearer $APPENDA_API_KEY"
Poll Get a run until status is final, or pass callback_url when you start
it: Appenda POSTs the ended run there, as Get a run answers it. records_found, records_empty and records_failed count the outcomes so
far.
5. Read the values
Get a record answers the field under its key:
curl https://api.appenda.app/v1/tables/tbl_67ad65ba34a7bbfc643711b8531cba3f/records/rec_e5d09fb0300a5d1ce095e03b7d6d1de4 \
-H "Authorization: Bearer $APPENDA_API_KEY"
The value is the part of the provider's answer that the field's output names,
or the whole answer when it names none.
When a record fails
The reason is on the record, not on the run. A failed record's value holds one
_appenda_error object:
| Member | What it holds |
|---|---|
type | The kind of failure. |
class | A stable class, such as auth_failed or rate_limited. |
label | A short description to show. |
message | A plain sentence that names the provider. |
action | Optional. buy_credits when the workspace is out of credits. |
New classes can appear, so treat an unknown one as a failure. A value without
_appenda_error is the provider's answer.