Zapier Integration Guide

The fastest path from zero to first successful Affino and Zapier transaction. Five steps, five minutes.

 

1. Create one profile. Go to Control > System > Zapier Profiles. Add one profile for one workflow only, choose the correct Zone, and enable a single method family.

 

2. Turn it live and copy the credentials. Save the profile, switch Live on, and copy the generated API Key and API Secret.

 

3. Connect Affino in Zapier. Add Affino as the app in Zapier and paste in the credentials from that exact profile.

 

4. Build one small test. Choose one trigger or one action only. For a simple first proof, use a small contact or account action, or one trigger you can immediately observe.

 

5. Verify in Affino, not only in Zapier. Check the record, then go to Control > System > Zapier API Logs and confirm the intended profile, method, result, and any warnings.

 

That is the first full loop. The rest of this guide goes deeper on profile design, supported method families, field mappings, and troubleshooting.

 

Before you start:

 

• You know which Affino Zone owns the workflow.
• You know whether you need triggers, actions, or both.
• You have picked the identifier strategy for updates.
• You can access Zapier Profiles and Zapier API Logs in Affino.

Use this matrix before you design a workflow in detail. It is the fastest way to answer the practical question, "can Affino and Zapier actually do this combination today?"

 

Affino's Zapier method set is broad, but it is not uniform. Some object families have both triggers and actions. Some are trigger-only. Some have important scope rules that are easy to miss.

 

Object family	Triggers	Actions	Important notes
Contacts	Contact add, edit, and delete activity	create_contact, update_contact	Use usercode for updates. Contact type and privacy rules matter.
Accounts	Account add, edit, and delete activity	create_account, update_account	Use accountcode for updates. Country fields use ISO plus name.
Contact Lists	Contact list created or updated and contact-added activity	create_contact_list, update_contact_list, add_contact_list_contact, remove_contact_list_contact	Contact Lists are not zone-specific. System and Auto-Assign lists are excluded.
Mailing Lists	Mailing list created or updated plus subscribe and unsubscribe activity	create_mailing_list, update_mailing_list, subscribe_contact_mailing_list, unsubscribe_contact_mailing_list	Mailing Lists are tied to the profile zone. Unsubscribe creates a real unsubscribe state.
Topic Lists / Topics	Separate topic-list and topic triggers	create_topic_list, update_topic_list, create_topic, update_topic	taxonomycode identifies the topic list; taxonomycategorycode identifies the topic.
Articles	article_published, article_updated	create_article, update_article	This is one of the deepest method groups. Field mapping matters.
Orders	Order triggers	None in current shipped scope	Action specs were discussed, but current shipped scope is triggers only.
Event Attendees	attendee_created, attendee_updated	None in current scope	Trigger-focused event operations.
Awards	award_entry_created, award_entry_updated	None in current scope	Awards payload includes entrant, nominee, order, and judges data.
Customer Signals	Customer Signal fired	trigger_customer_signal	Action only supports valid live Custom Triggers for the profile zone.

 

Two operating implications follow from this matrix.

 

First, do not enable methods just because they exist. If your profile is intended only for contact sync, do not also expose article, awards, and orders methods. The longer the method menu becomes, the easier it is to build or support the wrong Zap.

 

Second, do not assume that every object family behaves the same way. Contacts and accounts are straightforward create and update families. Contact Lists and Topic Lists have scope quirks. Articles are content-heavy and field-heavy. Orders, Event Attendees, and Awards are currently much more trigger-oriented than action-oriented.

 

Treat this matrix as the boundary of what you are designing. The remaining steps go object family by object family.

A Quick Start gets you to first success fast. This step is the slower, production-safe version: it explains what to configure on the Affino side, what to verify in Zapier, and what should count as a real proof of life before you expand the workflow.

 

In Affino:

 

1. Go to Control > System > Zapier Profiles.
2. Click add and name the profile after the workflow, not the department. Good examples: HubSpot Contact Sync - UK, Editorial Syndication - US, Awards Reporting - 2027.
3. Select the correct Zone.
4. Enable only the methods needed for this workflow.
5. If the workflow includes Customer Signals, select the signal set that this profile is allowed to expose.
6. Save the profile.
7. Turn Live on only when you are ready to test from Zapier.

 

On first save, Affino generates the API Key and API Secret for that specific profile. Those credentials belong to that one profile only. They are not generic site credentials, and they do not automatically expose every method family.

 

Profile settings that matter operationally:

 

• Name: the support label you will search for later in API Logs.
• Zone: the scope anchor for zone-aware objects such as articles, mailing lists, and many Customer Signal workflows.
• Methods: the contract defining what Zapier can see and call.
• Live: whether the profile is available to Zapier at all.
• Customer Signals selection: which signals the profile can fire or receive where that method family is enabled.
• Credentials: the API Key and API Secret generated from the profile itself.

 

In Zapier:

 

1. Add Affino as a connected app.
2. Paste in the API Key and API Secret from the intended profile.
3. Choose one enabled trigger or action only.
4. Map the minimum number of fields needed for a meaningful test.
5. Run Zapier's test step.

 

 

What should count as a real proof of life:

 

• the Zapier step completes
• the expected object is created, updated, or emitted
• the object lands in the expected Affino Zone where relevant
• the Zapier API Log row shows the intended profile and method
• any warnings in the row are understood before you keep building

 

 

Contacts and accounts are usually the first serious two-way workflows people build in Zapier. They are also the method groups most likely to break when the identifier strategy has not been thought through.

 

Contacts

 

Description

 

Contacts are the main person-level action family in the integration. Use them when Zapier needs to create or update an Affino contact from an external CRM, form, registration flow, or enrichment tool.

 

Example Usage

 

Zap: HubSpot new contact -> Affino create_contact firstname = Sarah lastname = Ellis email = sarah.ellis@example.com tel = +44 20 7946 0100 topics = Events|VIP

 

For later updates, keep the returned usercode in the external system and switch the action to update_contact.

 

Argument Reference

 

• usercode - (Required for update_contact, Optional for create_contact) Affino contact identifier.
• firstname - (Optional) Given name.
• lastname - (Optional) Family name.
• email - (Optional, but required when the resulting contact becomes Full Member) Primary email address.
• email2 - (Optional) Secondary email address.
• tel - (Optional) General or primary telephone number.
• businessphone - (Optional) Business phone number.
• mobile - (Optional) Mobile phone number.
• addressone - (Optional) First address line.
• addresstwo - (Optional) Second address line.
• towncity - (Optional) Town or city.
• countystate - (Optional) County, region, or state.
• postcode - (Optional) Postcode or zip code.
• country - (Optional) Country text value.
• membertype - (Optional) Contact or member type.
• privacytype - (Optional) Privacy setting.
• topics - (Optional) Pipe-delimited taxonomy values such as Events|VIP.

 

Attribute Reference

 

• usercode - Affino contact identifier returned by the contact record and used for future updates.
• firstname - Contact first name where present.
• lastname - Contact last name where present.
• email - Primary email where present.
• membertype - Contact type after the change.
• topics - Pipe-delimited topics where present.

 

Notes

 

 

 

 

 

Accounts

 

Description

 

Accounts are the organisation-level companion to contacts. Use them when Zapier needs to create or update a company, client, or parent organisation record in Affino.

 

Example Usage

 

Zap: external CRM company update -> Affino update_account accountcode = 44012 name = Example Publishing Ltd tel = +44 20 7000 1234 email = partnerships@examplepublishing.com countryiso = GB countryname = United Kingdom active = true

 

Argument Reference

 

• accountcode - (Required for update_account, Optional for create_account) Affino account identifier.
• name - (Optional on update, typically required in practice on create) Account name.
• notes - (Optional) Free-text notes.
• topics - (Optional) Pipe-delimited taxonomy values.
• accounttype - (Optional) Account-type classification.
• tel - (Optional) Main telephone number.
• email - (Optional) Main email address.
• web - (Optional) Website URL.
• companynumber - (Optional) Company registration number.
• vatnumber - (Optional) VAT registration number.
• accountmanager - (Optional) Affino account-manager value.
• address1 - (Optional) First address line.
• address2 - (Optional) Second address line.
• address3 - (Optional) Third address line.
• towncity - (Optional) Town or city.
• countystate - (Optional) County, region, or state.
• postcode - (Optional) Postcode or zip code.
• countryiso - (Optional) ISO country code.
• countryname - (Optional) Human-readable country name.
• parentaccount - (Optional) Parent-account label.
• parentaccountcode - (Optional) Parent-account identifier.
• active - (Optional) Account active state.

 

Attribute Reference

 

• accountcode - Affino account identifier used for future updates.
• name - Account name.
• email - Main email where present.
• topics - Pipe-delimited account topics where present.
• active - Current account active state.
• countryiso - ISO country value where present.
• countryname - Human-readable country value where present.

 

Notes

 

 

 

 

These method groups are where Affino's Zapier integration stops looking like a simple CRM bridge and starts looking like an audience and classification toolkit. They also contain several scope rules that are easy to miss.

 

Contact Lists

 

Description

 

Contact Lists are audience buckets for Affino contacts. They are unusual in this integration because they are not zone-specific, so the profile zone does not narrow list access in the same way it narrows articles or Mailing Lists.

 

Example Usage

 

create_contact_list name = Event Prospects description = Contacts who clicked event emails topics = Events|VIP contactsstatuslist = Invited|Registered|Attended

 

Then use add_contact_list_contact with the returned contactlistcode and the target usercode.

 

Argument Reference

 

• name - (Required for create_contact_list) Human-readable list name.
• description - (Optional) Free-text list description.
• topics - (Optional) Pipe-delimited topic values.
• contactsstatuslist - (Optional) Pipe-delimited list-status options.
• contactlistcode - (Required for update_contact_list, add_contact_list_contact, and remove_contact_list_contact) Affino contact-list identifier.
• usercode - (Required for add_contact_list_contact and remove_contact_list_contact) Affino contact identifier.
• status - (Optional for add_contact_list_contact) Contact-list membership status.

 

Attribute Reference

 

• contactlistcode - Affino contact-list identifier.
• name - Contact-list name.
• topics - Pipe-delimited list topics where present.
• contactsstatuslist - Pipe-delimited configured status values where present.
• usercode - Contact identifier on list-membership events.

 

Notes

 

 

 

 

 

 

 

Mailing Lists

 

Description

 

Mailing Lists are zone-scoped audience objects for communication and subscription workflows. Unlike Contact Lists, their create and update behaviour is tightly tied to section and subscription state.

 

Example Usage

 

create_mailing_list name = Weekly Briefing sectionname = Newsletters teaser = Top stories every Friday description = Editorial weekly digest live = true hidden = false

 

Argument Reference

 

• name - (Required for create_mailing_list) Mailing List name.
• sectioncode - (Required on create unless sectionname is used) Destination section identifier.
• sectionname - (Required on create unless sectioncode is used) Destination section label.
• teaser - (Optional) Short teaser text.
• description - (Optional) Mailing List description.
• live - (Optional) Live state.
• hidden - (Optional) Hidden state.
• unsubscribeconfirmationmessage - (Optional) Confirmation text used on unsubscribe.
• mailinglistcode - (Required for update_mailing_list, subscribe_contact_mailing_list, and unsubscribe_contact_mailing_list) Mailing List identifier.
• usercode - (Required for subscribe and unsubscribe actions) Affino contact identifier.

 

Attribute Reference

 

• mailinglistcode - Affino Mailing List identifier.
• name - Mailing List name.
• sectioncode - Section identifier where resolved.
• live - Live state where present.
• hidden - Hidden state where present.
• usercode - Contact identifier on subscription events.

 

Notes

 

 

 

 

 

Topic Lists and Topics

 

Description

 

Topic Lists define the taxonomy container. Topics are the individual taxonomy values inside that container. The integration supports both, but the identifier distinction matters a lot.

 

Example Usage

 

create_topic name = Awards taxonomycode = 42 topiccolor = FF6600 parenttopics = Events|Campaigns externalid = awards-category

 

Argument Reference

 

• title - (Optional for Topic List create and update) Topic-list title.
• description - (Optional) Topic-list description.
• publisher - (Optional) Topic-list publisher label.
• source - (Optional) Topic-list source label.
• language - (Optional) Topic-list language value.
• name - (Required for create_topic and typically on update_topic) Topic name.
• taxonomycode - (Required for create_topic unless topiclist resolves it) Topic-list identifier.
• topiclist - (Optional alternative to taxonomycode on create) Topic-list label.
• taxonomycategorycode - (Required for update_topic unless id is used) Topic identifier.
• id - (Optional alternative to taxonomycategorycode on update) Topic identifier.
• topiccolor - (Optional) Six-character hex value without #.
• customlink - (Optional) Custom URL or link value.
• externalid - (Optional) External topic identifier.
• parenttopics - (Optional) Pipe-delimited parent topic names or codes.

 

Attribute Reference

 

• taxonomycode - Topic-list identifier.
• taxonomycategorycode - Topic identifier.
• name - Topic name.
• topiccolor - Topic colour value where present.
• parenttopics - Pipe-delimited parent-topic values where present.

 

Notes

 

 

 

 

 

If you are using Zapier for editorial publishing or behavioural automation, this is the most important section of the guide. Articles and Customer Signals both expose deeper rules than the lighter CRUD-style methods.

 

Articles

 

Description

 

Article actions are designed for real publishing workflows, not just tiny metadata edits. The field surface is wider than it is for contacts or accounts, and the trigger payload is rich enough to drive downstream editorial, syndication, and alerting workflows.

 

Example Usage

 

create_article sectioncode = 12345 title = Spring Summit 2027 opens for registration teaser = Registration is now live for the annual summit. presentationstyle = Standard Article externalarticleid = hubspot-article-8812 topics = Events|Summit live = true mainimage = https://example.com/images/summit-hero.jpg

 

Treat the example section code and presentation style above as illustrative values. Use the real destination section code and a presentation style that exists on the target channel.

 

Argument Reference

 

• articlecode - (Required for update_article when updating by Affino article ID) Affino article identifier.
• externalarticleid - (Optional on create, Optional on update but commonly used) External article identifier.
• screenname - (Optional) External or friendly article slug value where used.
• title - (Optional on update, typically required in practice on create) Main article title.
• alternativetitle - (Optional) Alternate title.
• articletype - (Optional) Article-type value.
• sectioncode - (Required for create_article) Destination section identifier.
• teaser - (Optional) Short teaser text.
• summary - (Optional) Summary text.
• introduction - (Optional) Introductory rich-text field.
• text1 - (Optional) Rich-text body field.
• text2 - (Optional) Rich-text body field.
• text3 - (Optional) Rich-text body field.
• text4 - (Optional) Rich-text body field.
• text5 - (Optional) Rich-text body field.
• calltoaction - (Optional) Call-to-action text.
• quotationtext - (Optional) Quote text.
• informationboxtitle - (Optional) Information-box title.
• informationboxtext - (Optional) Information-box body.
• credits - (Optional) Credits text.
• thumbnailimage - (Optional) Remote image URL for the thumbnail slot.
• mainimage - (Optional) Remote image URL for the main-image slot.
• introimage - (Optional) Remote image URL for the intro-image slot.
• topimage - (Optional) Remote image URL for the top-image slot.
• baseimage - (Optional) Remote image URL for the base-image slot.
• image1 - (Optional) Remote image URL for image slot 1.
• image2 - (Optional) Remote image URL for image slot 2.
• image3 - (Optional) Remote image URL for image slot 3.
• categorytopic - (Optional) Category topic value.
• topics - (Optional) Pipe-delimited topic values.
• presentationstyle - (Required for create_article, Optional for update_article) Presentation-style name.
• multidisplay - (Optional) Comma-delimited section-code list for multi-display placement.
• live - (Optional) Live state.
• publishstart - (Optional) Publish-start datetime.
• publishend - (Optional) Publish-end datetime.
• pagetitle - (Optional) SEO page title.
• pagedescription - (Optional) SEO page description.
• priority - (Optional) Priority value.
• so - (Optional) Sort-order or related publishing value where used.
• securitycode - (Optional) Security-code value.

 

Attribute Reference

 

• articlecode - Affino article identifier.
• externalarticleid - External article identifier where present.
• title - Article title.
• articletype - Article-type value.
• sectioncode - Section identifier.
• teaser - Teaser text.
• introduction - Introductory body content.
• text1 to text5 - Main body fields.
• image fields - Image URLs plus related alt-text and caption variants where present.
• topics - Topic values where present.
• presentationstyle - Presentation-style value.
• live - Live state.
• created and updated timestamps - Publishing timestamps carried by the trigger payload.

 

Notes

 

 

 

 

 

 

 

 

Customer Signals

 

Description

 

Customer Signals work in both directions, but with tighter validation than the lighter method groups. Use them when Zapier needs to react to behavioural milestones or explicitly fire a lifecycle action against an Affino contact.

 

Example Usage

 

trigger_customer_signal conversioneventcode = 501 usercode = 88421

 

Argument Reference

 

• conversioneventcode - (Required) Customer Signal or Custom Trigger identifier.
• usercode - (Required) Affino contact identifier.

 

Attribute Reference

 

• usercode - Affino contact identifier.
• external user identifier - External identity value where present.
• first name - Contact first name.
• last name - Contact last name.
• primary email - Contact primary email.
• customer signal code - Signal identifier.
• customer signal name - Signal label.
• last triggered datetime - Timestamp of the most recent trigger event.

 

Notes

 

 

 

 

These method groups are important because they expose operational and commercial data, but they are not all equally mature as action surfaces. In current shipped scope, treat them primarily as outbound signal families.

 

Orders

 

Description

 

Orders are currently a trigger-led family. They are useful when Affino is the source of commercial truth and another system needs to react to purchases, fulfilment, payment state, or line-item detail.

 

Example Usage

 

Trigger: order updated in Affino Downstream Zapier actions: - send order summary to finance system - push fulfilment request to operations tool - update reporting sheet or warehouse

 

Argument Reference

 

• None in current shipped scope. Order actions were discussed during implementation, but the shipped scope is triggers only.

 

Attribute Reference

 

• customer identity fields - Customer-linked record information.
• billing address block - Billing address values.
• delivery address block - Delivery address values.
• invoice address block - Invoice address values.
• order_no - Order number.
• order_type - Order type.
• order_sub_type - Order sub-type.
• order_status - Order status.
• payment_method - Payment method.
• payment_provider - Payment provider.
• payment_amount - Payment amount.
• payment_date - Payment date.
• payment_status - Payment status.
• external and gateway references - Payment or commerce references where present.
• line_items array - Catalogue ID, item name, price, tax, quantity, totals, and currency information.

 

Notes

 

 

 

Event Attendees

 

Description

 

Event Attendees are currently a trigger family rather than an inbound-action family. Use them when downstream systems need to react to attendee creation, updates, or booking-linked profile changes.

 

Example Usage

 

Trigger: attendee_created Downstream Zapier actions: - notify event operations - send attendee to badge-printing workflow - update hospitality or accessibility checklist

 

Argument Reference

 

• None in current shipped scope. Event Attendees are exposed through triggers only.

 

Attribute Reference

 

• usercode - Affino contact identifier where the attendee is linked to a user.
• attendee first name - Attendee first name.
• attendee last name - Attendee last name.
• company - Company value.
• email - Email address.
• telephone - Telephone number.
• address lines - Address fields where present.
• town or city - Town or city.
• county or state - County, region, or state.
• postcode or zip - Postcode or zip code.
• country - Country value.
• special dietary needs - Dietary field.
• disability requirements - Accessibility field.
• custom1, custom2, custom3 - Custom attendee fields.
• attendee notes - Free-text notes.
• attendee type - Attendee type.
• created date - Created timestamp.
• related order fields - Order number, catalogue item, payment method, payment status, and order date where present.

 

Notes

 

 

 

Awards

 

Description

 

Awards are also trigger-led in the current implementation. Use them when downstream systems need to react to award-entry creation, award-entry updates, judging workflow, or related order data.

 

Example Usage

 

Trigger: award_entry_created Downstream Zapier actions: - notify awards operations team - create judging task in project tool - push entry summary into reporting workflow

 

Argument Reference

 

• None in current shipped scope. Awards currently expose triggers rather than inbound CRUD actions.

 

Attribute Reference

 

• award code - Award identifier.
• award name - Award label.
• category and category code - Category detail.
• award entry code - Entry identifier.
• company, team, or individual name - Entrant display value.
• entrant details - Includes entrantusercode and country ISO where present.
• nominee details - Nominee detail including country ISO where present.
• referencenumber - Reference number.
• datesubmitted - Submission date.
• entrystage - Entry stage.
• order number and payment fields - Order number, catalogue item, payment method, payment status, and order status.
• judges array - Judge detail returned with the entry.

 

Notes

 

 

 

The practical support story for Zapier in Affino lives in the log screens and service controls, not only in the trigger and action list. If Zapier says a step passed but the workflow still looks wrong, the Affino log is the source of truth.

 

Why the log matters

 

Zapier can tell you that a step completed. Affino can tell you what actually arrived, which profile handled it, which method ran, whether the request was accepted cleanly, and whether warnings were raised even though the top-line result looked successful. That is why experienced support work starts with the Affino log row, not with repeated blind retesting.

 

Row layout

 

A typical Zapier API Log row should be read like this:

 

Profile	Method	Result	Warnings	Timestamp
HubSpot Contact Sync - UK	create_contact	Success	none	2026-04-19 09:14:22

 

Use the row to answer five immediate questions:

 

• Profile - which Zapier Profile handled the request
• Method - which trigger or action ran
• Result - whether Affino treated the request as success, failure, rejection, or similar status
• Warnings - whether the request was accepted with adjustments, ignored values, or softer validation issues
• Timestamp - when the request hit Affino

 

Warnings versus errors

 

A successful row with warnings is not the same thing as a clean row.

 

• Success with no warnings means the request landed as expected.
• Success with warnings means the request was accepted, but something in the payload was adjusted, ignored, or only partially useful.
• Failure or rejection means the workflow did not complete in Affino and needs correction before retry.

 

Typical warning-style situations in this integration include:

 

• a Contact List status value that does not match a configured status and is therefore ignored
• a taxonomy value that cannot be resolved and is silently dropped
• a payload shape that is broadly valid but contains optional values that cannot be applied exactly as sent

 

Drill into a row, end to end

 

When a row looks wrong, open the row detail and walk it in this order:

 

1. Confirm the profile is the one you intended.
2. Confirm the method matches the Zap step you thought you were testing.
3. Read the request payload and compare it against the method's expected fields in this guide.
4. Read the response payload and check which identifiers, values, or validation messages came back.
5. Read any warning detail before you re-run the Zap.

 

That sequence is how you catch problems such as wrong profile credentials, the wrong identifier field, unresolved taxonomy values, duplicate external IDs, or a missing zone-specific configuration.

 

Pagination

 

Pagination support was added to improve reliability for larger trigger sets. In practice, this matters when one polling cycle needs to work through more than one page of results while preserving a stable timestamp window.

 

That matters most for higher-volume families such as:

 

• contacts
• accounts
• orders
• taxonomy-heavy methods
• other list-driven trigger families

 

Most Zapier issues in Affino come down to scope, identifiers, or expectations rather than dramatic system failure. Use this checklist before you rebuild a Zap from scratch.

 

What to avoid

 

• enabling more methods on a profile than the workflow actually needs
• building a two-way sync before one direction has been proved cleanly
• relying on email or free-text labels when a stable Affino identifier is available
• assuming a green Zapier test means the Affino side is clean without reading the API Log row
• treating polling-based triggers as if they were instant webhooks

 

If the expected trigger or action is missing in Zapier:

 

• confirm the profile is Live
• confirm the method is enabled on that profile
• confirm you used the credentials from the intended profile
• confirm the profile zone matches the records you expect to work with

 

If an update lands on the wrong record:

 

• check that you used the correct identifier field for that object family
• for contacts, that usually means usercode
• for accounts, accountcode
• for Contact Lists, contactlistcode
• for Mailing Lists, mailinglistcode
• for topics, remember taxonomycode is the topic-list identifier while taxonomycategorycode is the topic identifier
• for articles, confirm whether you intended to use articlecode, externalarticleid, or screenname

 

If article workflows fail or behave inconsistently:

 

• make sure sectioncode is being supplied on create
• make sure presentationstyle is valid for the channel and is supplied on create
• remember that duplicate externalarticleid on create returns 409 Conflict
• remember that only introduction and text1 to text5 preserve HTML as-is
• use a Zapier Filter step when you need narrower routing by section or article type

 

If list workflows seem odd:

 

• Contact Lists are not zone-specific
• System and Auto-Assign Contact Lists are excluded from Zapier actions
• Mailing Lists are zone-specific and require section resolution on create
• unsubscribe behaviour is not the same as ordinary removal from a list

 

If taxonomy workflows misbehave:

 

• use pipe-delimited topic strings where expected
• validate topiccolor as a six-character hex value
• double-check whether you are identifying the topic list or the topic itself
• remember that parent-topic links replace the previous set on update unless you omit the field

 

If trigger timing feels slow:

 

• the integration is polling-based, not instant
• pagination helps reliability on larger result sets, but not immediacy

 

If volume-related behaviour changes after go-live:

 

• check API Logs for warnings and paging patterns
• check whether the client's tier and usage volume are relevant

 

If you are using Customer Signals, Event Attendees, or other newer method groups:

 

• test the exact edge case you care about before go-live
• if something fails, inspect the Affino log entry first and compare the payload against the method's validation rules

 

Common questions

 

• Do I need one Zapier Profile per workflow? Usually yes. One profile per meaningful workflow keeps methods, logs, and support ownership much clearer.
• Should I store Affino IDs in the external system? Yes, where the system allows it. Persisting usercode, accountcode, contactlistcode, and similar identifiers is one of the biggest reliability improvements you can make.
• Can I treat the API Log as optional once the Zap works? No. The log is the operational truth when a workflow drifts, partially succeeds, or behaves differently at scale.

 

Good Zapier support in Affino comes from clarity more than heroics: clear profile boundaries, clear identifiers, clear expectations about polling, and disciplined use of API Logs.