Skip to main content

Onboarding Checklist

To accelerate the integration process, we use this central checklist for onboarding and technical API alignment.

⬇️ Download checklist as .md
Editing tip

You can copy the downloaded file, fill it out internally, and optionally add a status per item, e.g. ([Owner], [Date], [Comment]).

Branding & Assets​

For display in partner applications, we need your logo in different formats:

Logo requirements
  • Format: Preferably SVG (lossless scaling), or other common image formats.
  • Variants: One version for light backgrounds and (if available) one for dark backgrounds (Dark Mode).
  • Layout:
    • Long version: Full brand name with logo.
    • Square version: Reduced icon/signet (e.g. for favicons or compact views).

Technical Resources​

Depending on the integration scenario, we require different materials:

  • Scenario A (existing API):
    • Specifications: OpenAPI/Swagger files, Postman collections, or detailed documentation.
    • Auth details: URLs for auth server, token endpoints, client IDs/secrets (OAuth2), or authentication schemes.
  • Scenario B (new API based on the brokerize standard specification):
    • Implementation plan: Brief info on which parts of the coordinated standard specification (in progress, please contact us) will be implemented.
    • Deviations: Documentation of fields or endpoints intentionally implemented differently.

API Mapping & Feature Support​

In this section, we jointly validate the functional and technical fit of your API with the brokerize interface.

Authentication & Session TAN​

  • Session TAN: Does your API support a session TAN approach? Is TAN required for every portfolio action (e.g. placing orders), or is a session unlocked for a certain period?
  • Alternative methods: Which other approval methods are supported (e.g. app approval/push methods)?

Data Retrieval & Performance​

  • Pagination: Are large lists (order history, position lists) returned with pagination?
  • Date filters: Can order data be filtered by date ranges?
  • Historical depth: How far back is order history available via API?
  • API specifics: Are there technical constraints or special characteristics (e.g. no parallel requests, strict rate limits, sequential processing)?

Order Functionality​

  • Order models: Which types are supported? (Market, Limit, Stop, Stop-Limit, etc.).
  • Changes & cancellations: Can existing orders be changed (ChangeOrder) or only canceled and recreated?
  • Validity: Which validityTypes are available (day order, good-till-cancelled, etc.)?
  • Partial executions: Are partial executions supported? If yes, through which endpoint are these details provided?
  • Fractional trading: Is trading fractional shares possible? Are there limitations (e.g. only certain exchanges)?

Data Formats & Standards​

  • Timestamps: We can handle different date formats. Still, it helps to know whether your API outputs timestamps consistently. We prefer ISO 8601 format (e.g. 2023-10-27T10:00:00Z), ideally in UTC.
  • Currencies & performance: Amounts (prices, fees, taxes) must always include currency (ISO 4217, e.g. EUR, USD). For optimal performance display, it is ideal when all performance data (where possible) is delivered in portfolio/account currency.
  • Number formats: We prefer numeric values as strings or decimal types to avoid floating-point rounding issues.

Error Handling & Status Codes​

  • HTTP status codes: Consistent usage (e.g. 400 for validation errors, 401 for expired sessions, 422 for business logic errors).
  • Error messages: How does error handling work on broker side?
    • Are detailed error details included in API responses?
    • Does the API provide already translated error messages that can be forwarded directly to end users?
    • If no translated texts are provided: Can you provide a list of error codes with text proposals?

Advanced Features​

  • Special assets: Support for crypto trading or foreign currency accounts.
  • Additional info: Are order fees and taxes provided?

Test Access​

For development and quality assurance, at least one test account in the sandbox environment is required. Ideally, multiple accounts are provided to cover different scenarios:

  1. Regular account: Standard portfolio with (virtual) holdings and cash.
  2. Foreign currency account: An account with balances in different currencies (e.g. USD, CHF) to validate FX handling.
  3. Special configuration: Accounts prepared to test risk warnings, target market checks, or derivatives eligibility.

Configuration Data (for both scenarios)​

  • Exchange map: If multiple exchanges are supported, we need a list with IDs, short codes, and display names. A static list or endpoints to fetch this data are both fine.
  • Compliance: Any risk warning texts that must be shown to users before trading specific instruments (e.g. leveraged products, crypto).
  • Custody locations: How does your API handle different custody locations? If identified by IDs or abbreviations, we need a mapping of these values to user-friendly labels.

Next Step​

Once the checklist is initially completed and submitted, we review it on our side and schedule a meeting to align and agree on the next steps.