Apigee Migration Update

API Q&A
#1

Good afternoon,

As mentioned in the API Community Forum, Keap will be migrating our API Proxy provider from Mashery to Apigee on January 31st, 2020. We do not anticipate any downtime from this migration. We previously noted that we will be adjusting API quotas as part of this migration.For technical reasons, a change needed to be made in our rate limiting policy which means that we will shift from doing limits on a queries per second (QPS) methodology to queries per minute (QPM). In the new scenario, a consumer who had a rate limit of 25 QPS, for example, will now have a rate limit of 1500 QPM (25 queries per second * 60 seconds / minute). This will be a rolling window.In addition to that, the following headers will not be returned anymore:

  • X-Plan-*
  • X-PackageKey-*
  • X-Mashery-*

The response body for throttling and quota errors will still return HTTP 429, but the payload will be json error details.Here is an example of the response payload:

{
  "fault": {
    "faultstring": "Rate limit quota violation. Quota limit exceeded. Identifier : 2r42xxxxxxxxxxxx2",
    "detail": {
      "errorcode": "policies.ratelimit.QuotaViolation"
    }
  }
}

Here is an example of this is rolling window policy in 15 second increments for an account with a 1500 QPM limit:0:00 [1500 queries available] - 1000 queries made
0:15 [500 queries available] - 600 queries made - 100 queries fail
0:30 [0 queries available] - No queries can be made
0:45 [0 queries available] - No queries can be made
1:00 [1000 queries available] - 900 queries made - 200 queries fail
1:15 [600 queries available] - 300 queries made
1:30 [300 queries available] - 300 queries made
1:45 [0 queries available] - 100 queries made, 100 queries fail
2:00 [1000 queries available]

Please, let me know if you have any questions.

1 Like
#2
#3

Here are my questions, thanks:

  1. Will this move affect the Infusionsoft API itself or our use of it (other than the API quotas mentioned above)?

  2. How does this move from Mashery to Apigee affect the developer accounts for the developer Infusionsoft API client ID and client secret that are currently acquired via Mashery?

  3. Will registering for a developer account with Mashery still be required to use the latest API if one doesn’t already have an Infusionsoft API client ID and client secret via Mashery?

  4. If access, and/or previous methods to use or access the API will be changing at the end of this month, when will the documents and tutorials be updated to reflect the changes?

  5. The other post of yours I think you are referring to said, “We wanted to inform our developer community that the Infusionsoft Public API (REST and XML/RPC) will be going through a migration to a new provider over the next 6 weeks.”

    • Does that mean it will change at different times for different users, or that some of the services will be changing at different times, or what?
    • Does that also mean it should be complete by the end of 6 weeks (presumably from the December post)?
    • When are the changes due to be complete?

I was about to update from using a legacy API that used an API Key to using a more current API which uses a client ID and client secret. I’m now wondering if I should wait until after the 31st as registering for a developer account with Mashery may now be unnecessary, and something else may be required instead.

I don’t want to implement something new only to have it become obsolete practically right away, but I’m not sure how long I’d have to wait, or if things will be changing enough that waiting would be wise.

1 Like
#4
  1. The current only known breaking change is the error responses sent back when quotas are hit (described in the post)
  2. The client_id and client_secret records have already been imported into Apigee and we have been silently authenticating them for a few weeks.
  3. The Mashery Portal will be turned off on the 31st. All new keys will be created in a new Apigee Portal that will be live sometime this week.
  4. There will be no changes to how you access and use the API. We have been updating relevant documentation that should be reflected in the new Portal which go live sometime this week.
  5. We have been doing all the work necessary since December to ensure a seamless transition. We have already migrated traffic to Apigee which originally was just passing traffic on to Mashery. As of today we are silently verifying credentials and API product assignment (quotas, etc). Today we will most likely cut traffic over to stop calling Mashery and start having Apigee do all the token verification and quota enforcement. We attempted the cutover last week, but we had issues that caused a 15min outage. We have remedied the root cause of that outage and will be attempting this again today. This step has the most risk of all the work that has been done and will be done for the remainder of this week. As stated earlier Mashery will shutdown our proxy the end of the month, so we have a hard cutover date.

You should be able to move over to using OAuth now. We have push mechanism in place that is taking changes from Mashery and applying them to Apigee. So any new accounts should be created in Apigee as well. This can be verified by going to the new portal key management (https://keys.developer.keap.com) and register an account using the same email you used in Mashery.

If you see anything wrong please reach out and we can get it sorted.

Thanks,
Brad

1 Like
#5

Hey, @bradb,

When we talk about ‘new keys’, does this mean that the old public/private keys will be invalid for all existing integrations a developer has worked on?

#6

When I talk about keys I am talking about OAuth client_id and client_secret. We imported all of the existing ones from Mashery into Apigee.

#8

Hey @bradb - I’m seeing a change in the ‘expires_in’ field in the response of requesting a token. I believe that before that was returned as an integer and now it’s coming back as a string. This is causing all of our customers to become disconnected as we attempt to renew their tokens.

We’re working on patching the code, but is there anything we can do to reconnect all their apps without forcing a user to make that connection?

#9

Hi Brad, I read that you say that the migration will be perfect and that nothing will stop working when using the API, but I am having several problems, all the authentication stopped working, some already solved the problem and others not.

1 - when making calls to the API before I used Authorization bearer with lowercase b and it worked, now it doesn’t work, I had to switch to Bearer with uppercase B.

2 - The refresh Token stopped working, I still haven’t found why but it gives an error and if I want to do the authentication using the oAuth2 again it also gives me an error,

so it seems that several things stopped working and this migration was not transparent to us

#10

@Matt_Merrill: We’ve deployed an update to the proxy to convert that, you should be good to go now with those.

@Nilse_Alvarez: You should always provide headers in IETF RFC format (explicitly “Bearer” per https://tools.ietf.org/html/rfc6750#page-5 ). Mashery may have previously allowed a non-compliant behavior, but depending on it is bad practice.

If you’re experiencing an error on refresh, could you post the content of the of the error here? Is it returned from the API itself, or generated by an SDK and if so, which package?

#11