Daloopa API v3 — Release Notes & Migration Guide

Overview

Version: v3
Status: Available at https://app.daloopa.com/api/v3/
v2 status: Still available during the migration window (see Deprecation & timeline)

API v3 is a batched breaking-change release. Rather than shipping breaking changes piecemeal, we have grouped them into a single, clearly versioned upgrade so you migrate once.

The goals of v3 are:

• A single, consistent authentication scheme.
• Clearer, more accurate field names (calendar vs. fiscal periods).
• Removal of long-deprecated parameters and response fields.
• More scalable defaults (pagination and columnar exports).

v3 is a superset-minus-two of v2: every v2 endpoint is available under /api/v3/ except two that have been retired (see Removed endpoints). Endpoints not listed in this document behave identically to v2 — only their base path changes.

To migrate, update your base path from /api/v2/ to /api/v3/, adopt the required authentication format, and apply the field/parameter changes below.

Authentication (required for all v3 requests)

v3 accepts only the encoded email + API key authentication scheme. The legacy plaintext API-key scheme is not accepted on /api/v3/ endpoints and will result in an authentication error.

Requests must send:

Authorization: Basic base64(<email>:<api_key>)

You must update your authentication before calling any v3 endpoint. For the full specification and examples, see the authentication guide:

➡️ API Authentication

Note: v2 endpoints continue to accept both the legacy and the encoded schemes during the migration window. Only v3 makes the encoded scheme mandatory.

Breaking changes

1. Authentication is standardized

• What changed: v3 requires the encoded email + API key scheme (Authorization: Basic base64(email:api_key)). The legacy plaintext-token scheme is rejected on v3.
• Why: A single, consistent scheme removes ambiguity, improves security, and lets us retire the legacy path.
• Action required: Update your authorization header. See API Authentication.

2. Export defaults to Parquet

• Endpoint: GET /api/v3/export/{ticker}
• What changed: The export now returns a Parquet file by default. To continue receiving CSV, pass output_format=csv.
• Why: Parquet is columnar, compressed, and typed — significantly faster to transfer and load for analytical workloads.
• Action required: Update your parser to handle Parquet inputs. For pandas for example, you can simply replace read_csv with read_parquet to get the same dataframe

3. Companies endpoint is now paginated

• Endpoint: GET /api/v3/companies
• What changed: The response is now paginated and includes pagination metadata (e.g. count, next, previous, results) instead of returning the full result set in a single response.
• Why: Pagination keeps responses fast and reliable as coverage grows, and gives you predictable page sizes.
• Action required: Iterate through pages instead of expecting the entire list in one response.

4. Companies response — quarter fields renamed

• Endpoint: GET /api/v3/companies
• What changed: earliest_quarter and latest_quarter are removed. Use earliest_calendar_quarter and latest_calendar_quarter instead.
• Why: The new names make explicit that these values are calendar quarters, avoiding confusion with fiscal quarters.
• Action required: Update field references in your integration.

5. Deprecated period parameters removed (Fundamentals, Documents, Search)

• Endpoints:
  • GET /api/v3/companies/fundamentals
  • GET /api/v3/documents
  • POST /api/v3/documents/keyword-search
  • POST /api/v3/documents/keyword-search-with-positional-information
• What changed: The deprecated periods request parameter is removed (and, for the Documents lookup endpoint, the deprecated single period parameter is removed as well). Use the explicit calendar/fiscal parameters instead:
  • Fundamentals: use calendar_periods instead of periods
  • Documents & Search: use calendar_quarters instead of periods
• Why: The old periods/period parameters were ambiguous about calendar vs. fiscal periods. The explicit names remove that ambiguity. For V2, periods query parameter represents a calendar quarter, so if you are using periods , you can replace directly with calendar_*
• Action required: Replace periods/period with the corresponding calendar_* parameter.

6. Deprecated response fields removed

• What changed: Deprecated fields that duplicated a newer, clearer field have been removed from v3 response payloads where present — for example, the deprecated period field on the Documents response (use calendar_quarter / fiscal_quarter).
• Why: Removing duplicated/ambiguous fields keeps payloads lean and unambiguous.
• Action required: Read the current, explicitly named fields (calendar_quarter / fiscal_quarter).

7. Taxonomy — sub_industry_id filter removed

• Endpoints: GET /api/v3/taxonomy/metrics, GET /api/v3/taxonomy/metrics/{id}
• What changed: The sub_industry_id query parameter is removed. Filter by company_id, series_id, or keywords.
• Why: Sub-industries are being retired in v3 (see below), so sub-industry-based filtering is no longer offered.
• Action required: Remove sub_industry_id from taxonomy metric requests.

Removed endpoints

The following v2 endpoints are not available under /api/v3/:

If you use either endpoint today, please migrate off it before moving to v3.

Quick migration checklist

1. Base path: change /api/v2/ → /api/v3/.
2. Authentication: switch to Authorization: Basic base64(email:api_key) — required on all v3 requests. See API Authentication.
3. Fundamentals: replace periods with calendar_periods (or fiscal_periods).
4. Documents & keyword search: replace period/periods with calendar_quarters (or fiscal_quarters); read calendar_quarter/fiscal_quarter in responses.
5. Companies: page through results; read earliest_calendar_quarter / latest_calendar_quarter.
6. Export: expect Parquet by default; add output_format=csv if you need CSV.
7. Taxonomy: remove sub_industry_id.
8. Retired endpoints: stop calling taxonomy/sub-industries and series-continuation.

Deprecation & timeline

• v2 remains available during the migration window and is unchanged. Existing integrations will continue to work while you migrate.
• v2 will be sunset after the migration window. We recommend migrating to v3 as soon as practical.
• We will communicate the v2 sunset date separately.

Need help?

• Authentication: https://docs.daloopa.com/docs/api-authentication
• For migration questions, contact your Daloopa representative or our support team.