Questions to settle before a Marketo event integration goes live

The plan on the whiteboard is reasonable. Registrations flow into Marketo as they arrive, the confirmation journey fires, a nurture track runs to show open, and after the show a scored list goes to sales. Two systems, one arrow between them, three weeks of work.

The arrow is where the interesting decisions are, and a Marketo event integration hides most of them behind numbers nobody looks up until something stops. The four that decide the design are all published, and reading them before the build changes what gets built.

What the published numbers are

Adobe (2026) documents the constraints on the Marketo REST API plainly. "Each subscription is allocated 50,000 API calls per day. The quota resets daily at 12:00 AM CST." Beneath the daily allocation sits a rate limit: "Each instance is limited to 100 API calls per 20 seconds." And there is a concurrency ceiling: "Each instance allows a maximum of ten concurrent API calls." Bulk work carries its own constraint, with "Bulk API calls support a maximum body size of 10 MB."

Four numbers, and each one governs a different failure. Fifty thousand a day is the ceiling on total volume. One hundred per twenty seconds is the ceiling on speed. Ten concurrent is the ceiling on parallelism. Ten megabytes is the ceiling on how much you can hand over in one go.

The daily allocation is the one to look at first, because 50,000 is a smaller number than it sounds once every system in the building is pointed at the same instance.

How long does a 5,000 lead push take?

Take the standard post-show job: 5,000 leads, pushed one record per call.

One hundred calls per twenty seconds is five calls a second. Five thousand calls divided by five is 1,000 seconds, which is 16.7 minutes of continuous running at the ceiling with no margin for anything else touching the instance.

Against the daily allocation, 5,000 calls is 10 per cent of 50,000. Fine as a one-off. Schedule it hourly during an open sale and 24 runs is 120,000 calls, which is 240 per cent of the allocation, so the integration dies somewhere around ten in the morning and the rest of the day's registrations sit in a queue nobody is watching.

Now add the second call. If the integration queries Marketo to find an existing lead before deciding whether to create or update, that is 10,000 calls for the same 5,000 records, 33 minutes of running and 20 per cent of the day. Use the endpoint that resolves the match server side against a deduplication field and you halve both figures for an afternoon of work.

Concurrency turns out not to be the binding constraint for this shape of work. Ten concurrent calls at, say, 200 milliseconds each would deliver 50 calls a second, and the rate limit caps you at five, so the parallelism is spare capacity. Where concurrency does bite is on slow calls, and bulk export jobs are the slow ones.

The allocation is also shared, which is the detail that turns a comfortable design into a tight one. Fifty thousand calls a day covers the whole subscription, so your registration sync competes with the web form integration, the sales team's CRM sync, whatever the agency plugged in last year, and any list export somebody runs by hand. If four other consumers are each spending 6,000 calls a day, your real budget is 26,000 rather than 50,000, and a job sized against the published figure is sized against a number that was never available to you. Ask for the current consumption before you size anything.

When does the daily quota actually reset?

At midnight US Central time, which is almost certainly not midnight where your scheduler runs.

Central Standard Time is six hours behind UTC, so a reset at 12:00 AM CST lands at 06:00 UTC. For a team in London that means the overnight job at 02:00 is spending the previous day's allocation, and the job at 07:00 is spending the new one. For a team in Singapore it means the reset arrives in the afternoon. Daylight saving moves the boundary by an hour twice a year in each direction, so the gap between your local midnight and the quota reset is not even constant.

None of this matters until the day you are close to the ceiling, and then it matters completely, because the difference between a large reconciliation job scheduled at 03:00 and one scheduled at 08:00 is which day's 50,000 it comes out of. Write the reset time into the runbook in UTC alongside your own local schedule, and put the large jobs immediately after it.

Bulk is metered separately, and that changes the plan

The single most useful design question is whether a given load belongs on the record endpoints at all.

Bulk import and bulk extract exist for volume work and carry their own constraint of a 10 MB maximum body size. Five thousand lead records at roughly 500 bytes each is about 2.5 MB, so the whole post-show push fits inside one bulk import with room to spare, and it costs a handful of API calls to create the job, upload the file, poll for status and read the result rather than 5,000 calls to write the records one at a time.

Extract behaves differently again and is the direction that surprises people. Pulling activity history out of Marketo is asynchronous, jobs queue, and a large extract can occupy one of your ten concurrent slots for a long time. An integration that fires several extracts in parallel because it is impatient can starve the real-time path that the confirmation email depends on, and the symptom will be slow confirmations rather than a failed extract.

The rule that comes out of this is worth writing down before the build starts. Real-time path for the single record, bulk path for anything over a few hundred, and never let a bulk job and a real-time path share a concurrency budget without a limit on the bulk side.

What the connector does and what it leaves to you

If your registrations originate in Cvent, some of this is already bridged. Cvent (2026) lists Marketo among its integration partners and describes the connector's job in terms of contact movement, including the ability to "Import and export contact records in bulk between Cvent and Marketo".

Contact movement is a genuinely useful thing to have solved and it is worth being precise about what it does not solve. A contact is a person. A registration is a person plus an event, plus a registration type, plus a status, plus a moment in time. A connector that keeps person records in step across two systems leaves you to decide how the event-shaped facts are represented on the Marketo side, and that decision is the one your campaign team will live with.

The common answer is a program membership per event with progression statuses, which works well and needs a naming convention agreed up front, because five shows named five different ways is a reporting problem for as long as the instance exists. Whatever the registration platform can hand over cleanly is worth establishing first, and planning that export so it is reusable is a separate exercise with its own field list.

The questions to settle before go live

Six, and they take an afternoon between two people.

What is our actual daily call consumption today, before this integration exists? Somebody is already using the instance and the answer is rarely zero.

Which loads are real-time and which are batch, with a number attached to each?

What is the deduplication field, and does the registration platform's person identifier get written to it?

What happens to a registration that fails to write? A dead letter queue that somebody reads beats a log line that nobody does.

How far back does activity history reach in each system, because a five year campaign attribution question needs both sides to have kept the data, and establishing the history limits first prevents a scoping conversation in month three.

And what is the naming convention for programs, so that show A in 2026 and show B in 2026 sort together.

Where this stops

Getting the API arithmetic right produces an integration that does not fall over. It does not produce a good one, and two limits are worth naming.

The first is consent. A registration form for one show captures permission for that show's communications, and a bulk import will happily place all 5,000 records into a portfolio-wide nurture. The API has no opinion about this and neither does the connector. Whoever designs the program structure has to carry the consent scope with the record, and that is a design decision made once rather than a filter applied later.

The second is that timing guarantees are weaker than they look. A real-time write followed by a program membership followed by a smart campaign trigger is a chain of asynchronous steps, and under load each of them queues. A confirmation email that arrives in four seconds during testing can arrive in four minutes during a launch spike, and no amount of API tuning on your side changes what happens inside the campaign engine. If a same-minute confirmation is a requirement, send it from the registration platform and let Marketo own the sequences that follow.

Start with a measurement rather than a design. Take 5,000 records from your last show, push them through your intended path into a sandbox, and time it with a clock. Then read the API consumption for that hour. Those two numbers, measured on your own data, will tell you more about whether the plan works than any estimate, and the same exercise against a different marketing platform has a different set of ceilings to measure against. The rest of what integrations owe each other sits with this cluster.