New developer here on the IPP platform. I'm trying to understand the difference between the NG and QB domain IDs, so please correct any mistakes in my assumptions below:
Records created in Quickbooks Desktop only have "QB" domain id.
Records created via the API have both a "QB" and "NG" domain id. The default id is "NG" if idDomain attribute is ignored.
If the record is created via the API, the "QB" domain id is in the ExternalKey tag.
Do I have it right?
Records created in the cloud (via the API) have an NG domain, which is basically their unsyncronized primary key.
Once they get synced to QuickBooks desktop, they then get a QB domain ID value as well (the QB ID is the syncronized primary key from within QuickBooks).
You should be able to refer to any record by either the NG or QB ID.
What you indicated in your above post sounds correct.
Related
I'm investigating a migration process from a legacy system into keycloak. Based on some of the ideas here: https://github.com/Smartling/keycloak-user-migration-provider we're looking to create user accounts in keycloak at the point of login by looking up user credentials from some dedicated endpoints on our legacy system.
As part of this, I need the user ID to remain the same as it was in the legacy system.
Is it possible to create a user with a specified ID rather than relying on keycloak to auto-generate it?
Running into this issue when attempting to create users via the API, I looked into the code for the users service. It looks like it is currently not possible to set the user id due to how the user is created.
From the code in https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UsersResource.java specifically on line https://github.com/keycloak/keycloak/blob/7cfe6addf01676939206e034a87c791460031032/services/src/main/java/org/keycloak/services/resources/admin/UsersResource.java#L115 the user is first created using the username, then updated. I believe id is not an updatable field. Thus it is not currently possible.
Checking the api I see it is now possible to add an optional "id" field in the userRepresentation object that you pass to create a new user in keycloak.
Find more information here: https://www.keycloak.org/docs-api/5.0/rest-api/index.html#_userrepresentation
I have recently integrated with G Suite to use it as a SAML 2.0 IdP for my application. When configuring the SAML app through the G Suite control panel you are only able to map some basic employee attributes like First Name, Last Name and Primary Email Address.
Previously our application has been used with ADFS which is also configured to send an immutable ID. The intention of this is if someone gets married or otherwise changes their name, their email address will likely also change. By matching on the immutable ID we are able to update our record on our application with the new details.
However, if someone was to change their email + name in Google we are unable to determine that this may be an old account by a different name.
I've noted that you can add custom attributes to Users and can probably map these through but we wouldn't want to impose this on consumers of our SaaS. I see that there is an Employee Id attribute but this doesn't appear to be selectable on the SAML mapping screen.
Before first sending signing request I should get a accountId.
So is there any expiration time for this accountID? Can I save it and use it any time with unlimited time if there is no changes in credential or/and other api key and so on?
I can't find information about strategy for accountId in rest api documentation.
Thank you
ref:
https://www.docusign.com/developer-center/recipes/request-a-signature-via-email
https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST API References/Login.htm
The account ID is part of your developer account. You can find it when you login by clicking on the little down arrow in the top right corner next to your avatar. It will display your name the name of the company then a number. That is the account ID.
The account ID does not expire. The way DocuSign manages access to the API's is through an Integrator key. For information about the Integrator key please refer to the following link. https://www.docusign.com/developer-center/api-overview
So from a broad overview you would want to break up the different business processes by business group and have a different Integrator Key for each unit. That way if someone builds bad code or something strange happens and they turn of one of the Integrator keys it does not affect every group in the company.
There is no expiration of your accountId however note that it will change between environments - i.e. when you move from demo to production. Therefore the best practice is to write your integration such that, for a given user, it makes the login call then uses the accountId returned from that in subsequent API requests. By writing it this way you also make the go live process easier since you wouldn't have to remember to go back and change any hard-coded values in your app.
Note that when you are in production, your organization (or your customers' organizations) may well have more than one account id. And that individuals within the organization may well have access to more than one account.
Example: a company has different rules for electronic signature requests that are sent from the legal department and all the other corporate departments. Depending on the differences in the rules, the best DocuSign configuration may be to establish two different accounts, one for legal and one for everybody else. And some people may have access to both accounts.
Bottom line: when your API integration app logs in, it should enable either the human or your config file to specify the account that should be used (if the user has access to more than one account.) While all users have a "default account," it is not always the case that the default is the one that should be used by your integration.
I just set up our first live merchant on Balanced Payments and am looking to credit them. In the account creation process, I received the redirect request in my code, I followed that.
I entered in the merchant data and account information, and was successfully redirected back to my site with the account URI and email.
I can successfully retrieve the account via the API, but I do not see it listed in the accounts list page on my balanced dashboard. Is there possibly some lag time before a new live merchant account would show up?
When Balanced creates a merchant for you via the KYC process, you're not passing any authentication information to the API which means Balanced does not have the ability to create objects within your account. This is important to note because:
Balanced will create a Merchant which represents an identity within the Balanced system (this identity is not associated to any particular marketplace), but it doesn't create the actual Account on your marketplace.
The documentation notes that it is the URI of this Merchant which is returned to you, however you will need to then use this identity to create an Account within your marketplace. You are able to do this as you have an API key to authenticate the request.
Here is an example of creating the account using the Balanced Ruby client:
# URL looks like https://yoursite.com/kyc/complete?email_address=merchant#exam
# ple.org&merchant_uri=/v1/merchants/MR3KJZgnQcg8OX8FrTWlRszn
merchant_uri = params[:merchant_uri] # alter to your framework for GET params
email_address = params[:email_address]
merchant = Balanced::Marketplace.my_marketplace.create_merchant(
email_address,
merchant_uri
)
With the new request id system request id are composed of 2 parts, the request id and the user id. The documentation
says you must delete the request id using the full id of the request but if the user has no accepted the application you can't have his id? Before when you accessed to the request you have a to field containing information about the user but now it's gone if the user haven't accepted the application?
So my question how access to the user id if he hasn't accepted the application? It clearly express that we need to delete the request but without the user id it can't be done).
I'm having the same issue in my own app. I've submitted a bug report since there doesn't seem to be any way of doing so (even though the Javascript SDK seems like it should work at first glance) https://developers.facebook.com/bugs/239476836116522