Error 601 from api -> reauthenticate -> error 601 again

[Anonymous]

I've been having an issue with some code we use, where I'm getting a 601 error response from the API, but when I re-authenticate, the next request also fails with a 601.

{"requestId":"5c99#15f16354ea4","success":false,"errors":[{"code":"601","message":"Access token invalid"}]}]


Re-authenticating should fix the problem according to here: http://developers.marketo.com/rest-api/error-codes/#response_level_error_codes

Has anyone run into this? Is this a bug on Marketo's side? Could it be caused by any setting in the Marketo account?

[Anonymous]

Creating a new API-Only User and a new LaunchPoint Service fixed the issue. I suspect that when the setup was done the first time, the user wasn't made an api-only user.

[Nicholas_Manojl]

On the other end, I'd double check there isn't a typo in the URL or the way the paramaters are included,

eg., ?access_token="xxxx"?fields=firstname

[Anonymous]

I don't think that the expiration is the reason you're getting an error, as instead of 602 code you keep on getting 601. Try to enter in your browser https://xxx.mktorest.com/rest/v1/lead/1.json?access_token=yyy, where xxx is your rest endpoint id and yyy is your token. You should get 1004 error code (or the lead, if you have lead with id #1).

If you get 601 code — well, it basically means that your token is invalid.

[Anonymous]

I get {"requestId":"acfd#15f264682e9","success":false,"errors":[{"code":"601","message":"Access token invalid"}]}

This is the token give by marketo's api verbatim, so I'm not sure why it's invalid.

The documentation I linked above says:

An example of this is a 601, “Access token invalid,” which is recoverable by re-authenticating and passing the new access token with the request

[Anonymous]

You should read it this way: An example of this is a 601, “Access token invalid,” which is recoverable by re-authenticating and passing the new correct access token with the request

Get access token here: https://xxx.mktorest.com/identity/oauth/token?grant_type=client_credentials&client_id=yyy&client_sec...

xxx — client endpoint, yyy — client id, zzzz — client secret. Is the response ok? Does it have access_token and expires_in params? Do you treat it as json utf8 encoded response?

[Anonymous]

The response is a 200. It has access token and expires_in fields. It's being treated as utf-8 json. It looks in every way like a normal api response. The code handling the response is the same code that's used for other client endpoint/id/secret combos, and it has worked with them for a few years.

Does this indicate a problem with the endpoint/id/secret? If so, why am I getting this error about the token after a successful api call to "identity/oauth/token" instead of an error to the token api?

[Anonymous]

Hmm.. something is really wrong here. Have you tried to enter your get request into browser address bar and see how it goes? Also I'd try passing token as http auth header. It's not a solution, of course, as you won't fix the problem but it could lead you to understanding what's going on.

[Kenny_Elkington]

Typically when I see this happen, it's because the code doesn't actually replace the previous access token after reauthenticating, it simply passes the old invalid one.  Have you checked your logs to compare the the access_token values which are passed before and after encountering the 601 in your client?

[Anonymous]

I've confirmed that it does correctly use the new access token and it does not reuse the old one, both in the code and by manual testing it. I've also done this manually using the python `requests` library and bypassing all our code, and reproduced the results there.

Could this be caused by an incorrect id/secret? I'd think that if that were the case, I'd see an error on the identity api call.

[Kenny_Elkington]

It's possible.  Are you submitting the identity request and rest request to the same host, e.g. aaa-999-aaa.mktorest.com?  If the hosts are different you'd see what you're describing

[Anonymous]

All to the same host.

[Kenny_Elkington]

If you create a new custom service and use those credentials, do you have the same issue?  Beyond that, I'd suggest you open a support case and include examples calls/responses where you've observed this.

[SanfordWhiteman]

which is recoverable by re-authenticating and passing the new correct access token with the request

"This error is recoverable. Simply don't try that again."

[SanfordWhiteman]

Can you check your local system clock to make sure it hasn't slipped?

[Anonymous]

Requests made from the same machine around the same time work, it's only this one set of credentials that's exhibiting the issue.