Route leads created via API/integration (source = integration) bypassing forms logic

Outcome. A contact created through an API integration gets the same default properties and routing treatment a form submission would have given it, instead of arriving incomplete because it never touched a HubSpot form.

Workflow map Enrollment, branches and actions at a glance lead-routing-048

flowchart TD
    A[Contact created via API/integration] --> B{Territory unknown?}
    B -->|Yes| C[Set default Territory]
    B -->|No| D{Lifecycle Stage unknown?}
    C --> D
    D -->|Yes| E[Set Lifecycle Stage = Lead]
    D -->|No| F{Consent required and unknown?}
    E --> F
    F -->|Yes| G[Add to API-created - needs consent review]
    F -->|No| H[Mark Backfilled Defaults Applied = true]
    G --> H
    H --> I[Standard routing workflow enrolls normally]

When to use it, when not to

• UseUse it whenever contacts enter the portal through a connected app or a direct API call (a custom integration, a legacy CRM migration feed, a partner system) rather than a HubSpot form, and currently skip properties that forms normally set (hidden fields, consent defaults, an initial Territory or Lifecycle Stage).
• UseUse it as a backfill-and-route step that runs once per contact, feeding the standard routing workflow (lead-routing-001 or similar) once the missing defaults are filled in.
• SkipDo not use it if the integration already sets every property a form would; there is nothing to backfill, route these directly through the standard workflow.
• SkipDo not use it to backfill legal or consent-related properties silently. If forms normally capture explicit consent, an API-created contact skipping that step needs a genuine compliance decision, not an automatic assumption of consent, see Known pitfalls.