2

My use case is similar to Web-to-Lead: we collect user data, then add it to salesforce as new lead. I would like to upgrade to the API for higher reliability and fine-grained control.

I believe I can simply write an Apex class and expose it via REST. The hard question is authentication. I don't fit the standard OAuth case -- this is server to server communication, and I don't want a user to have to log in. Nor do I feel like the hassle of creating a callback URI listener in my web application.

I have a web server which sits at a static IP, and that is the only IP that needs to do this. You would think this could be used in some way.

At the moment, the best I'm coming up with is:

  1. Create an "API only" user (which costs a bit, but OK), and
  2. Ensure my static IPs are listed as trusted in salesforce, so that I don't need a user security token
  3. Send a SOAP login request as the API user, and get the session ID
  4. Call my APEX class, using the session ID as authorization
  5. Logout (optional?)

This is not the most efficient flow as I have to do the last 3 steps for each request.

3

Have you seen Quick Tip – Public RESTful Web Services on Force.com Sites and Can I have a public APEX REST API?

You expose the REST API to the apex class via a Force.com site. This bypasses the need to authenticate the request.


The alternative is to carry on with a dedicate API user as you suggested. I use this approach and it works fine. In most cases I stick with using the security token and setting the API user to have a password that doesn't expire.

If you can keep an active session Id on the server and not logout after each request you will get better performance. Only update the Session Id if you detect that it has become invalid.

Don't call logout - it will invalidate all your sessions. Could cause problems with other requests in progress.

  • Fantastic -- thank you! I had no idea this feature existed. I've decided to use Web-to-Lead for this specific problem, submitting the form in code so I confirm it went through, but we have some other use cases coming up where this will be VERY handy. – Erica Kane Jun 28 '16 at 13:13
  • I just realized, we have Professional Edition with API, but as it is not a full Developer Edition I don't have the ability to make APEX classes, it seems. I have to look into pricing but that is likely going to limit me. – Erica Kane Jun 28 '16 at 21:04
  • @EricaKane Yes, PE with API will be much more limiting than an Enterprise Edition org. – Daniel Ballinger Jun 29 '16 at 0:20
1

Keep your session ID and reuse it as often as possible. In theory, it should be more like "repeat step 4 indefinitely." If you're worried about your session expiring, you might want to use SOAP getServerTimestamp() once an hour to keep your session alive. 24 API calls/day is a small price to pay to avoid having to login each time. Otherwise, simply make the call, and if it fails because it's not authorized, then log in again and retry the call.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.