Expose Archived Program Flag & Improve Program Membership API for Large-Scale Instances | Community
Skip to main content
C
Chargotra
Level 3
February 17, 2026
New

Expose Archived Program Flag & Improve Program Membership API for Large-Scale Instances

  • February 17, 2026
  • 2 replies
  • 25 views

Hello Marketo Community,

 

We are currently operating a large Marketo instance and are facing scaling challenges related to program membership data extraction via the REST/Bulk APIs.

 

 

Current Limitation

 

At present:

 

  1. There is no API-exposed field that identifies whether a Program is archived.

  2. Archiving a program in the UI (e.g., moving it to an archived folder) does not translate into a machine-readable “archived” flag via the REST API.

  3. The Program Membership Bulk API requires filtering by Program ID.

  4. There is no supported endpoint to retrieve program membership changes between two timestamps without iterating through individual Program IDs.

 

Because of this, integrations must iterate across all program IDs to ensure no membership changes are missed — even for programs that are long archived and no longer operational.

 

 

Business Impact

 

For instances with thousands of programs:

 

  • API calls increase significantly as program volume grows.

  • Sync runtimes increase over time, even if most programs are inactive.

  • There is no supported way to exclude archived/inactive programs from recurring membership checks.

  • This creates scaling and performance constraints for downstream data integrations and analytics platforms.

 

 

Requested Enhancements

 

We would like to request consideration for one (or more) of the following improvements:

 

  1. Expose an “archived” (or equivalent) boolean flag via the REST API

    This would allow integrations to safely exclude archived programs from ongoing membership syncs (assuming archived programs cannot have membership updates).

  2. Allow bulk program membership export without requiring Program ID filters

    For example, enabling exports based purely on time windows (start/end timestamps) rather than per-program iteration.

  3. Introduce an endpoint to retrieve program membership changes between two timestamps

    This would dramatically reduce the need to scan all program IDs during each integration cycle.

 

 

Why This Matters

 

As program volume grows over years of usage, performance and API efficiency become critical. These enhancements would:

 

  • Improve scalability for enterprise customers

  • Reduce unnecessary API consumption

  • Improve sync performance for data warehouse integrations

  • Enable better architectural patterns for reporting and analytics

    2 replies

    Darshil_Shah1
    Community Advisor and Adobe Champion
    Darshil_Shah1Community Advisor and Adobe Champion
    Community Advisor and Adobe Champion
    February 17, 2026

    There are a couple of workarounds:

    • With the Get Programs REST endpoint, you get the folder id -- which can be used to query whether the folder is archived or not (Get Folders REST endpoint's response has the isArchive flag in it.
    • If you need to run this update only for programs created within the past week/days/month(s), you can include that in the earliestUpdatedAt filter in the Get Programs call. This way, you won't be querying all the programs in your DB -- only the most recent ones based on your use case would be queried, which would most likely all be unarchived (since they're recent).

    I hope you find this helpful.

    C
    ChargotraAuthor
    Level 3
    February 17, 2026

    Hi Darshil,

    Thanks for the suggestion — appreciate the input.

    In our case, the constraint is specifically at the Program Membership Bulk API level, which requires explicit programIds. While we can technically infer archive status via folderId → Get Folders (isArchive), this does not help reduce the program membership scan unless we build and continuously maintain a dynamic program allowlist/denylist, which adds complexity and still doesn’t address the core API limitation.

    Additionally, using earliestUpdatedAt on Get Programs isn’t viable for us because program membership changes can occur in older programs whose program metadata hasn’t been recently updated, so filtering by recently updated programs risks missing valid membership activity.

     

    Our need is to safely reduce membership scan scope at scale without risking data gaps, which currently isn’t possible with the existing API design.

    Darshil_Shah1
    Community Advisor and Adobe Champion
    Darshil_Shah1Community Advisor and Adobe Champion
    Community Advisor and Adobe Champion
    February 18, 2026

    Hi ​@Chargotra, thanks for the clarification. That makes sense!

    I agree with you that once we’re talking specifically about the Program Membership Bulk API, the core limitation is architectural: membership extraction is tightly coupled to explicit programIds, and there’s no time-window-based delta endpoint at the membership level. IMO, at scale, that becomes progressively more expensive as program volume grows, even if most programs are operationally inactive/archived.

    In large instances, I’ve seen three patterns emerge (none perfect, but worth considering):

     

    1. Instead of deriving eligibility dynamically from archive status, you can maintain an external list of “programs eligible for membership sync.” This registry list is updated according to defined rules (e.g., last membership activity, operational status, and business unit ownership). It’s extra governance, but it decouples membership extraction logic from Marketo folder structure.

     

    2. Rather than polling membership by program, you can pull from the Bulk Activity API for (works greate in certain architectures):

    • Add to Program

    • Change Program Status

    Then reconstruct membership state downstream in the warehouse. This shifts the integration model from “scan every program” to “capture every delta event.” It’s heavier downstream, but more scalable API-wise (especially via bulk activity extract API).

     

    3. It's also a good idea to enforce a process that archived programs must not receive membership updates (including status changes from smart campaigns). If that governance is technically enforced, archived programs can be safely excluded from the membership registry without risk of silent drift.

    But fundamentally, I agree with your enhancement ask. A time-bound membership delta endpoint (or global membership export without programId constraint) would significantly improve scalability for long-running enterprise instances. Right now, the API model scales linearly with historical program growth, which is not ideal for customers with multi-year program accumulation.

    Would definitely support this as a formal product enhancement. :)

    Terms & ConditionsAccessibility statement

    Loading footer...