Discussions

We are a longtime Daylite customer developing an internal CRM data-quality monitoring workflow using Make.com.

We want to establish a dedicated, read-only OAuth connection for automated monitoring and verification. This connection must not be able to create, edit or delete Daylite records.

Before registering an application, we would appreciate guidance on three questions.

1. Read-only OAuth scope

Can an internal OAuth application be registered using only the daylite:read scope, without granting daylite:write?

Is there a recommended registration procedure for an application used solely within one customer organization?

2. Make.com OAuth compatibility

Make supports a generic OAuth 2.0 Authorization Code client with configurable authorization/token endpoints, parameters and redirect URI.

Can Daylite's OAuth endpoints be used with Make's generic client?

In particular, Daylite's documentation references scopes and authorization_code. Does Daylite accept the standard OAuth parameters scope and code, or are specific mappings required?

Our proposed redirect URI is:

https://www.integromat.com/oauth/cb/oauth2

Please confirm whether this is acceptable for application registration.

3. Unattended token refresh

Daylite access tokens are documented as expiring after approximately one hour.

Are there specific refresh-token handling requirements, expiration limits, or other configuration steps necessary for a recurring unattended Make scenario?

Our intent is to use this read-only connection for research and monitoring. Any CRM modification process would remain separately controlled and subject to explicit approval.

We would appreciate the API team's recommended configuration before proceeding.

Thank you,

Bob Rinaldi
Rinaldi Advisory Services