Transaction Recording on POST only - any advice?
We have a product contains 2 proxies one of which is a POST, and one a GET. During the POST preflow the GET is called using the same apikey to verify the user is authorized for this POST.
We created a package that has a rate plan that bills 1 cent per 200 OK request. When we make a request, however, this rate plan bills 2 cents. It seems to be billing for both calls that are made.
We tried disabling the authorization call out and indeed, the plan only billed one penny.
Question: how can I limit the tx recording policy so it only bills once, for the successful POST? I'm still digging but any help would be marvelous.
Thank you
does both the calls have the same request path ? if not, api product allows to specify multiple paths. Once there are multiple paths, separate transaction recording policies can be configured per path. So leave the authorization specific path unchecked.
Also note that success criteria default value is "200". Make sure to use anything other than txProviderStatus == '200', If default is used, even unchecked resources are treated success
Hoping this helps!
Thanks, Rajanish we always appreciate a response! I did not add that in slightly more detail, the "auth" callout uses the same apikey to answer the question "are you who you say you are" and "have you registered these devices (printers) for use."
Each of the proxies just uses a "/" resource path unfortunately. So in configuring the tx recording policy we can't tinker with paths. In fact, in certain error conditions the monetization charged one penny because one of the two proxies "succeeded" in producing a mint.tx.status = 200.
We have a workaround which is less than perfect from a developer portal experience:
Create 2 products (one for the POST proxy, one for the auth callout proxy); bundle them in one package. Set the POST tx recording to be legit (txProviderStatus == '200') and set the auth tx recording policy to txProviderStatus == 'ZZZ', something that will never trigger mint.tx.status. This successfully only bills once.
The unfortunate side effect is that on the developer portal when creating an app, the user will need to check the box to add BOTH products to their app.
The other option is tinker proxy implementation to set a custom variable to identify success/fail and use that variable to determine success criteria
So in that case, auth proxy will not set this variable at all. So you could avoid developer to choose two products
That sounds doable and will give that a try, Rajanish. I will let you know what we end up with.
