API Connection | Community
Skip to main content
Level 1
April 13, 2026
Solved

API Connection

  • April 13, 2026
  • 1 reply
  • 20 views

Hi everyone,

I’m currently setting up an API connection to push data into Marketo and would appreciate some guidance.

We’ve created a service in LaunchPoint and now have the Client ID and Client Secret. Our goal is to enable the engineering team to create leads in Marketo via the API.

However, I’m a bit unsure about the authentication flow. The access token generated via “Get Token” is only valid for one hour, and I’m concerned that sharing a temporary token could cause the connection to break once it expires.

Could someone clarify what credentials or details should be shared with the engineering team to ensure a stable integration? Also, how should the token refresh process typically be handled in this setup?

Thanks in advance for your help!

Best answer by SanfordWhiteman

You never share the access token ahead of time. Share the Client ID & Client Secret. The app fetches an access_token and uses it until it expires, i.e. when it receives a code 601 from the API. Then fetch a new one. It’s a basic auth/expire/refresh sequence!

 

The only thing you might put on top of that (but absolutely don’t need to) is a check to see if it’s been, say, 70 minutes since the last use. In that case you know the token will have expired, so you can immediately fetch a new access_token instead of wasting a call that’s guaranteed to return a 601. Don’t try to time this precisely to 3600 seconds, you’ll never get it right due to clock drift, but if you start at 70 minutes you know you’ll be in the expired zone.

1 reply

SanfordWhiteman
SanfordWhitemanAccepted solution
Level 10
April 14, 2026

You never share the access token ahead of time. Share the Client ID & Client Secret. The app fetches an access_token and uses it until it expires, i.e. when it receives a code 601 from the API. Then fetch a new one. It’s a basic auth/expire/refresh sequence!

 

The only thing you might put on top of that (but absolutely don’t need to) is a check to see if it’s been, say, 70 minutes since the last use. In that case you know the token will have expired, so you can immediately fetch a new access_token instead of wasting a call that’s guaranteed to return a 601. Don’t try to time this precisely to 3600 seconds, you’ll never get it right due to clock drift, but if you start at 70 minutes you know you’ll be in the expired zone.